Patent ID: 12198189

DETAILED DESCRIPTION

I. Overview

Example systems and associated methods described below provide means for risk control in a distributed electronic trading environment. According to one example method, a central risk management may establish communication with a local risk management. Upon establishing the communication, the local risk management module may receive from the central risk management module a portion of a central risk account balance to create a local risk management balance for a trading account. When the local risk management module receives an order request from a trading entity using the trading account, the local risk management module may determine if there is a sufficient balance available in the local account balance to forward the order request to a computerized matching process. If the balance is sufficient, the local risk management may forward the order request to the computerized matching process without any need to communicate with the central risk management module. The central risk management module may replenish the local account balance either automatically or upon receiving a request from the local risk management module. Additional embodiments related to risk management according to the example embodiments will be described below.

While the example embodiments are described herein with reference to illustrative embodiments for particular applications, it should be understood that the example embodiments are not limited thereto. Other systems, methods, and advantages of the present embodiments will be or become apparent to one with skill in the art upon examination of the following drawings and description. It is intended that all such additional systems, methods, features, and advantages be within the scope of the present invention, and be protected by the accompanying claims.

II. A First Example Trading System

FIG.1illustrates an example electronic trading system in which the example embodiments may be employed. In this example, the system comprises a trading station102that accesses an electronic exchange104through a gateway106. Router108is used to route messages between the gateway106and the electronic exchange104. The electronic exchange104includes a computer process (e.g., the central computer) that matches buy and sell orders sent from the trading station102with orders from other trading stations (not shown). The electronic exchange104may list one or more tradeable objects for trade. While not shown in the figure for the sake of clarity, the trading system may include other devices that are specific to the client site like middleware and security measures like firewalls, hubs, security managers, and so on, as understood by a person skilled in the art.

The computer employed as the trading station102generally can range from a hand-held device, laptop, or personal computer to a larger computer such as a workstation and multiprocessor. An illustrative personal computer uses Pentium™ microprocessors and operates under a Windows 2000™, Windows NT™, or Windows XP™ operating system. Generally, the trading station102includes a monitor (or any other output device) and an input device, such as a keyboard and/or a two or three-button mouse to support click based trading, if so desired. One skilled in the art of computer systems will understand that the present example embodiments are not limited to any particular class or model of computer employed for the trading station102and will be able to select an appropriate system.

The computer employed as the gateway106generally can range from a personal computer to a larger computer. An illustrative gateway106computer uses Pentium™ microprocessors and operates under a Windows 2000™ or Windows NT™ (server or workstation) operating system. Generally, the gateway106may additionally include a monitor (or any other output device), input device, and access to a database, if so desired. One skilled in the art of computer systems will also understand that the present example embodiments are not limited to any particular class or model of computer(s) employed for the gateway106and will be able to select an appropriate system.

It should be noted that a computer system that may be employed here as a trading station or a gateway generally includes a central processing unit, a memory (a primary and/or secondary memory unit), an input interface for receiving data from a communications network, an input interface for receiving input signals from one or more input devices (for example, a keyboard, mouse, etc.), and an output interface for communications with an output device (for example, a monitor). A system bus or an equivalent system may provide communications between these various elements.

It should also be noted that the trading station102generally executes application programs resident at the trading station102under the control of the operating system of the trading station102. Also, the gateway106executes application programs resident at the gateway106under the control of the operating system of the gateway106. In other embodiments and as understood by a person skilled in the art, the function of the application programs at the trading station102may be performed by the gateway106, and likewise, the function of the application programs at the gateway106may be performed by the trading station102.

The actual electronic trading system configurations are numerous, and a person skilled in the art of electronic trading systems would be able to construct a suitable network configuration. For the purposes of illustration, some example configurations are provided to illustrate where the elements may be physically located and how they might be connected to form an electronic trading system; these illustrations are meant to be helpful to the reader, and they are not meant to be limiting. According to one example illustration, the gateway device may be located at the client site along with the trading station, which is usually remote from the matching process at the electronic exchange. According to this instance, the trading station, the gateway, and the router may communicate over a local area network, and the router may communicate with the matching process at the electronic exchange over a T1, T3, ISDN, or some other high speed connection.

In another example illustration, the client site may be located on the actual grounds of the electronic exchange (for example, in the building of the exchange). According to this instance, the trading station, the gateway, and the router may still communicate over a local area network, but the router may communicate with the matching process at the electronic exchange through another connection means besides a T1, T3, or ISDN.

In yet another example illustration, the gateway may be housed at, or near, its corresponding electronic exchange. According to this instance, the trading station may communicate with the gateway over a wide area network or through the use of a T1, T3, ISDN, or some other high speed connection.

In another example illustration, the gateway may be located remote from the trading station and remote from the electronic exchange, which might be particularly useful in systems that include interconnection of multiple trading networks. Thus, one trading network might have gateway access to an electronic exchange. Then, other trading networks may communicate with the trading network that has gateway access through a T1, T3, ISDN, or some other high speed connection.

III. A Second Example Trading System

FIG.2illustrates another example trading system that uses similar computer elements as shown inFIG.1, in which, the example embodiments may be employed to trade at multiple electronic exchanges. The system comprises a trading station202that can access multiple electronic exchanges204and208. In this particular embodiment, electronic exchange204is accessed through gateway206and electronic exchange208is accessed through another gateway210. Alternatively, a single gateway may be programmed to handle more than one electronic exchange. Router212is used to route messages between the gateways206and210and the electronic exchanges204and208. While not shown in the figure, the system may include other devices that are specific to the client site like middleware and security measures like firewalls, hubs, security managers, and so on, as understood by a person skilled in the art. Additional electronic exchanges may be added to the system so that the trader can trade at any number of exchanges, if so desired.

The trading system presented inFIG.2provides the trader with the opportunity to trade tradeable objects listed at different electronic exchanges. To some traders, there can be many advantages with a multi-exchange environment. For example, a trader could view market information from each tradeable object through one common visual display. As such, price and quantity information from the two separate exchanges may be presented together so that the trader can view both markets simultaneously in the same window. In another example, a trader can spread trade different tradeable objects listed at the different electronic exchanges.

As indicated earlier, one skilled in the art of electronic trading systems will understand that the present embodiments are not limited to the particular configurations illustrated and described with respect toFIG.1andFIG.2, and will be able to design a particular system based on the specific requirements (for example, by adding additional exchanges, gateways, trading stations, routers, or other computers serving various functions like message handling and security). Additionally, several networks, like either of the networks shown inFIG.1orFIG.2, may be linked together to communicatively access one or more electronic exchanges.

IV. An Example Risk Control System

The example system described below distributes centralized risk management data so that trading is generally not delayed by communication with a centralized risk component, while still providing centralized risk control and management. According to one example embodiment that will be described in greater detail below, a centralized risk component allocates a fraction of the central risk account balance to a local risk component that can be located at a gateway. The localized risk component may then manage a local risk balance without communicating with the central risk component until the local account balance is high enough to allow submission of trades corresponding to the received order requests. Then, as the local account balance gets low, the local risk component may communicate with the central risk component to obtain an additional account balance. This example method as well as additional functional aspects of the example system will be described in greater detail below.

FIG.3illustrates an example distributed risk management system300, in which, the example embodiments for distributed risk management may be employed. The system300includes trading stations302and304that can access multiple electronic exchanges336and338. In this particular example, the exchange336can be accessed through a gateway “A”318, and the exchange338can be accessed through a gateway “B”320. Alternatively, each gateway can provide access to both exchanges. A router322is used to route messages between the gateways318and320and the electronic exchanges336and338. The system300also includes risk management components. More specifically, a central risk controller306includes a risk management module308that is used to control, allocate, and manage risk related parameters corresponding to the trading stations302and304. The risk parameters can include, but are not limited to a current available credit, an available margin to place a trade, and/or trading related risk data, such as an overall net position, a filled net long position, a filled net short position, an open net position, the current profit/loss level (“P/L”), working outright orders, or the combination thereof. Those skilled in the art will understand that many additional risk-related parameters could be used as well. In general, it should be understood that any equation including one or more parameters that control trading could be used as well for managing risk allocated to each trading stations302and304.

In addition to the central risk controller306, each gateway318and320is associated with a local risk management component324and330that locally manage risk corresponding to orders received at each respective gateways, the details of which will be described in greater detail below.FIG.3illustrates the components324and330being internal with respect to each gateway. However, it should be understood that, in an alternative embodiment, each gateway could communicate with a standalone localized risk management components as well.

According to one example embodiment, it will be assumed that the trading stations302and304use a single trading account for conducting trades at the electronic exchanges336and338through the gateways318and320. However, each trading station could have its own trading account or multiple trading accounts. The trading account includes one or more risk related parameters described above that are used for risk management. For the purpose of this example, let's assume that a risk related parameter that is used in relation to the trading account is a monetary account balance available for trading to the trading stations302and304, such as, for example, $5,000.

According to one example embodiment, the central risk controller306may allocate a portion of the total account balance corresponding to the trading account to each local risk management component324and330. The local risk management components324and330may then locally manage risk data based on the provided risk account balance. According to the example using $5,000 as the total available account balance, the risk management module308could allocate the balance of $1,000 to each local risk management component324and330. In such an embodiment, the local risk management components324and330could locally manage the risk as one or more orders are being sent through each gateway up to the limit of its allocated funds, such as $1,000 in this example. As the local account balance gets low, the local risk management components324and330can communicate with the centralized risk controller306to obtain additional funds. It should be understood that different account amounts could be allocated to each gateway based on any preset rules. Methods of communications between the centralized risk controller306and localized risk management modules324and330to allocate and manage local accounts at each local risk management component will be described in greater detail below in relation to the subsequent figures.

According to one example embodiment, each risk management component creates and dynamically updates risk data records corresponding to one or more trading accounts or traders.FIG.3illustrates one such configuration in relation to each risk management component. For example, each record created at the risk management component308may include an account identifier field, an account balance field, and local allocation records, such as, gateway balance allocation records, “GW A” and “GW B” allocation records, in this example.FIG.3illustrates one example record created at the risk management component308for a trading account being used by the trading stations302and304. The account record includes an account identifier of “9999” shown at310corresponding to the trading stations302and304, an account balance of $3,000 as shown at312, and the fund balance that was allocated to each gateway, $1,000 in this example, as shown at314and316. It should be understood that each balance related entry can be updated based on how the funds are allocated between the localized risk management modules. Also, it should be understood that additional data could be stored in each record, and the illustrated record is only an example. For example, additional entries could be created when more than two gateways are used by a trading station to send orders to one or more exchange. Also, while the example record show risk parameter in the format of the available trading funds, different risk related parameters discussed above could be used at the central risk controller306in addition to or instead the available trading funds.

Similarly to the centralized records being kept at the risk management module308, gateways318and320may create and update its own account records once risk data corresponding to a specific account is allocated to each of them, therefore eliminating the need to communicate with the central risk controller306to manage risk associated with each trade order to be sent to an electronic exchange through the gateways. One example set of records is illustrated in relation to the local risk management modules324and330, with each record using a client “ID” field and “Balance” field, with specific entries shown at326,328,332, and334. As mentioned in relation to the example provided earlier, $1,000 was allocated to each local risk management module324and334for local risk management of trades made from the trading stations302and304using the account labeled “9999,” in this specific example.

It should be understood that the system300shown in relation toFIG.3is only an example, and different changes in the system configuration could be made to accomplish the same functionality. For example, rather than keeping risk management records at each gateway, each gateway could communicate with a standalone database that could store the records. Also, a single local risk management module could be used for more than two gateways that are placed at the same location.

Different methods related to the functional aspects of the distributed risk management system will be described in relation to the subsequent flowcharts. It should be understood that each block in the flowcharts may represent a module, segment, or portion of code, which includes one or more executable instructions stored on one or more computer readable media for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the example embodiments in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention. Also, the flowcharts will be described in relation to the components illustrated inFIG.3. However, it should be understood that more, fewer, or different components could also be used to execute the methods described below.

FIG.4is a flowchart describing an example method400for allocating a risk account balance to a local risk management module. At step402, the central risk controller306receives a central risk balance data corresponding to a trading account created for a trading entity. According to one example embodiment, the central risk balance and the corresponding trading account may be defined by a system administrator or could be communicated to the central risk controller306from another entity. As mentioned earlier, the trading account could be used to control trades initiated from one or more electronic trading stations and/or different automatic trading tools that automatically generate orders to be sent to an electronic exchange. The trading account could be identified by a trading identifier. While the example embodiments described herein use a monetary balance as means for risk management, it should be understood that the example embodiments are not limited to the use of monetary balances. For example, non-monetary metrics could be used as well as means by which the example systems can measure and control risk. For example, the risk could be controlled and measured based on any other trading related parameters, such as a total net position that a trader/trading entity is allowed to hold at any given time, a working order quantity, or a number of tradeable objects that can be traded at any given time. Also, statistical risk measures, such as volatility, the number of traders logged in, or yet some other parameters, could be used as well.

At step404, the central risk controller306receives a request to allocate to a local risk management module, such as324, a fraction of the central risk balance corresponding to the defined trading account. According to one example embodiment, the request could be communicated from the local risk management module, such as when a first order request is received at a gateway associated with the local risk management module from one of the trading entities that use the central trading account. Alternatively, the request could be communicated from the trading entity itself upon detecting a trader or some other automated trading tool initiating trading. Alternatively, the request could be generated internally at the central risk controller306upon detecting one or more preset conditions. The conditions that can be used to trigger the allocation may be based on the trading history, predefined current events, or the combination thereof. For example, upon allocating a risk account balance to one local risk management module corresponding to the first gateway, the central risk controller306could use a trading history record corresponding to the trading entity to determine that there is a likelihood of trades being sent through a second gateway corresponding to a different localized risk management module. In such an embodiment, the allocation request for the different localized risk management module could be triggered upon detecting that a trader is trading at the first gateway. The conditions could be preprogrammed.

At step406, the central risk controller306determines if there is a central account balance to fulfill the request. To do that, the central risk controller306may use the account identifier provided in the request to determine if there is any central account balance corresponding to the trading entity. If there has been no central account balance created for the trading entity, or the balance has been completely used, at step408, the central risk controller306may reject the request by sending a rejection request message to the local risk management module. According to an alternative embodiment, even if there is no central account balance, the central risk controller306could shift at least a portion of the available balance from one local risk management module to the requesting module, the methods of which will be described in relation to one of the subsequent figures.

If there is sufficient central account balance available, at step410, the central risk controller306determines a fraction of the balance corresponding to the central account to be provided to the local risk management module. According to one example embodiment, the central risk controller312could allocate the requested portion of the central risk account balance to the local risk management module. Alternatively, the central risk controller312could provide a smaller balance than the requested one. According to one example embodiment, the central risk controller312could be programmed with a number of balance allocation rules to be used for dynamically allocating the account balance between the local risk management modules. The rules could be preprogrammed or could be based on a trading history, such as for example, the number of trades being sent through a gateway corresponding to the local. risk management module, or the traded quantity corresponding to orders being sent via the gateway as compared to other gateways that a trader uses or may use during a trading day. Different account allocation criteria could be used as well.

At step412, the central risk controller312provides the allocated risk account balance to the requesting local risk management module. According to one example embodiment, the central risk controller312may send a risk data allocation message to the local risk management module, and the message could include risk data to be managed at the local risk management module. At step414, the central risk controller312updates the central account records so that the records reflect the allocation of the central risk balance to the local risk management module. More specifically, the available balance corresponding to the central account is decreased by the allocated balance, and a record for the local risk management module is either created or updated with the newly allocated balance. As described above, many different risk parameters could be used, and a separate risk balance could be created and managed for each parameter. For example, one account balance could be created and managed for a net position, while another account could be associated with the monetary credit still available for trading.

FIG.5is a flowchart describing an example method500for using and managing a risk account balance at a local risk management module. At step502, a local risk management module receives an account risk balance to be used in relation to making risk determination for trades that are initiated at a trading entity. The local risk management module may create or update an account record corresponding to the trading entity to reflect the current available risk account balance. At step504, the local risk management module detects a new trade request from the trading entity. According to the embodiment, the request could be communicated from another component at a gateway that receives order requests from the trading entity.

At step506, the local risk management module determines if there is a sufficient local account risk balance to complete the requested trade order. For example, when a monetary risk account balance is used, the local risk management module may subtract the account balance required to complete the trade from the total account balance to see if there would be any account balance remaining after completing the trade. As mentioned earlier, different risk related parameters, other than monetary credits, could be used as well in relation to the risk accounts being kept at the local risk management module and the central risk management module. Also, more than one risk related parameter could be monitored at any given time before sending an order to an electronic exchange.

If there is a sufficient balance at the local risk account, at step508, the local risk management module updates the risk balance of its local account and allows the order request to be sent to the electronic exchange. However, if the local account balance is not sufficient, at step510, the local risk management module may send to a central risk controller306a request for an additional account balance. According to one example embodiment, the additional balance requested by the local risk management module may be equal to the balance necessary to allow the order request to be sent to the electronic exchange. Alternatively, a higher balance could be requested as well.

At step512, the local risk management module determines if a sufficient risk account balance necessary to complete the order request was received from the central risk controller. If so, the method500continues at step508, and the trade order request is sent to the electronic exchange. However, if the local risk management module does not receive any additional balance or the received balance is still not sufficient for the trade order to be sent to the electronic exchange, the local risk management module rejects the trade order request, as shown at514. According to one example embodiment, a gateway corresponding to the local risk management module may responsively send an order request rejection message to a trading station that initiated the order.

According to another embodiment that was mentioned earlier, rather than using the central account balance to allocate additional balance to one or more local management modules, the central risk controller could shift the funds from a local management module that has a big risk account balance left to the one that needs an additional balance. An example method600for shifting an account balance between two local risk management modules will be described in relation to a flowchart illustrated inFIG.6.

Referring toFIG.6, at step602, the central risk controller receives a request from a first local risk management module for an increase of a local risk account's balance associated with a trading account. At step604, the central risk controller determines if there is a sufficient account balance left in the central risk account to fulfill the request. If the account balance is sufficient, at step606, the central risk controller may provide the requested balance or a higher additional balance to the first local risk management module. As mentioned earlier, the central risk management module may be configured with a set of risk allocation rules that may control allocation of the additional funds to the local risk management modules.

Referring back to step604, if the balance in the central risk account is not sufficient, at step608, the central risk controller may query a second local risk management module for the current local account balance associated with the trading account. At step610, the central risk controller receives the current account balance information from the second local risk management module. At step612, the central risk controller determines if there is sufficient local account balance available at the second local risk management module to allocate a portion of that balance to the first local risk management module. It should be understood that this determination could be based on a number of rules, such as a minimum account balance to be held at the local risk management module, time of day, trading activity corresponding to a gateway that uses a local risk management module, and many others.

As shown at612, if the account balance at the second local risk management module is not sufficient to shift it to the first local management module, the method terminates. If there is sufficient account balance, at step614, the central risk controller may send new balance allocation messages to both the first and second local risk management modules. According to the example given in relation to the method600, the message to the first local management module would include a balance increase request, and the message to the second local management module would include a balance decrease request. At step616, the central risk controller may update its account records corresponding to the first and second local risk management module to reflect the current balance allocation.

It should be understood that different changes could be made with respect to the method600. For example, some method steps could be omitted. According to one alternative embodiment, the central risk controller could monitor the orders being made from the trading stations and could automatically update the records corresponding to different local risk management modules based on the trades that were managed by each module. In such an embodiment, the steps of608and610of querying the local management modules for their current account balances and receiving the local account information at the central risk controller could be omitted since the central risk management module would at least have an approximate account balance for each or at least some modules. Also, while the method600was described in relation to a single local management module being queried by the central risk controller, the steps of the method600could be repeated in relation to other local management modules that could be used to manage and control risk account balance corresponding to the same trading account.

FIGS.7A and7Billustrate a flowchart that illustrates an example method700for automatically monitoring and allocating an additional account balance at a local risk management module.

At step702, a central risk controller allocates a risk balance to a first local risk management module and a second local risk management module based on a central risk account balance available for a trading account. As mentioned earlier, many different account balance allocation rules could be used. Also, the trading account could be used by many different trading entities.

At step704, the central risk controller monitors trading activity at each local risk management module. To do that, the central risk controller could monitor orders being sent from trading entities associated with a trading account via gateways associated with each local management module. According to one example embodiment, the central risk management controller could receive order information from the trading entities. Such information could be either provided dynamically as the trade orders are being submitted, or periodically based on some preset time settings that could vary based on time of day, or some other market or trader related events that may be thought of as triggering submission of orders.

At step706, the central risk controller updates its account records corresponding to each local risk management module based on the trading activity corresponding to the trading account. Additionally, each local risk management module may periodically send to the central risk management module a current risk account balance corresponding to the trading account. At step708, the central risk controller detects that an additional risk balance might be needed at the first local risk management module. According to an example embodiment, this determination may be based on the local account balance being kept and dynamically updated at the central risk management module, as well as one or more account allocation rules that determine the account balance to be provided to each local risk management module.

At step710, the central risk controller determines if sufficient balance is left in the central risk account to provide the additional balance to the first local risk management module. If there is sufficient balance, at step712, the central risk controller provides the additional balance to the first local risk management module. It should be understood that the additional balance allocated to the first local risk management module can be based on balance allocation rules being used at the central risk management module to allocate risk account balance to local risk management modules.

Referring back to step710, if the central account balance is not sufficient to allocate the additional balance to the first local risk management module, at step714, the central risk management module determines if there is sufficient account balance at the second risk management module. According to one example embodiment, the sufficient account balance would be at least the additional account balance needed at the first risk management module. If there is no sufficient account balance, the method700terminates. If there is sufficient account balance available, at step716, the central risk controller determines if at least a portion of the balance at the second local risk management module can be shifted to the first local risk management module. Such determination may be based on many different account balance allocation rules. For example, the account balance allocation rules could include a minimum account balance rule, a trading activity record that can be used to determine the account balance that may be needed at each local risk management module, etc.

If the central risk management module determines that at least a portion of the local balance at the second local risk management module cannot be shifted to the first local risk management module, the method700terminates. Otherwise, at step718, the central risk management module shifts at least a portion of the local balance at the second risk management module to the first local management module. The allocation of the balance could be accomplished by sending new allocation messages to the first and second local risk management modules. More specifically, an account balance increase message including a request to increase the account balance level would be sent to the first local risk management module, and an account balance decrease message including data including a request to decrease the account balance level would be sent to the second local risk management module.

Also, while not specifically described above, two local risk management modules could directly communicate with each other to shift account funds corresponding to a trading account. In such an embodiment, upon the allocation of the funds, one of the gateways could communicate with the central risk management module to provide the updated account information for central record keeping purposes at the central module. It should be understood that the central risk management module could control which local risk management modules could directly arrange a balance transfer with another local modules. For example, a number of rules could be programmed that control which local risk management modules could directly communicate at any given time. Also, it should be understood that the limitations could be based on an account with respect to which funds are to be transferred.

It will be apparent to those of ordinary skill in the art that methods involved in the system and method for multi-market risk control may be embodied in a computer program product that includes one or more computer readable media. For example, a computer readable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications or transmission medium, such as, a bus or a communication link, optical, wired or wireless having program code segments carried thereon as digital or analog data signals.

The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.