CA2799155A1 - Out of band credit control - Google Patents

Abstract

Systems and method for mediating risks associated with orders in an electronic trading system are provided. A front end component includes a plurality of trading engines that receive orders from traders. A back-end component includes a match system. The system includes a credit control module, which may be located at the back-end (e.g., clearinghouse), front end, a combination thereof, or other location that communicates with the plurality of trading engines. The credit control may monitor aggregate risk parameters for the trading engines and requests credits from trading engines.

Description

OUT OF BAND CREDIT CONTROL

]01] This international application claims priority to U.S. patent application Serial No.
12/778532, entitled, "Out of Band Credit Control," filed 12 May 2010; which is a continuation-in-part of U.S. patent application Serial No. 11/841,258, entitled, "Out of Band Credit Control," filed August 20, 2007, both applications are herein incorporated by reference in their entireties.

FIELD OF THE. INVENTION

1021 The, present-`invention relates to-credit control and risk management in.a-.distributed derivative product trading environment. More particularly, the present invention relates to out of band credit control monitoring.

BACKGROUND
1031_ Computer systems .and networks' increasingly are being, used to trade ;securities and derivative products. Computer systems>and,networks provide~several Advantageswfien comparcd'to-manual methods of trading. Such advantages include' increased accuracy;
reduced labor costs and the ability to quickly disseminate market information.

]04] Options are frequently traded via computer systems. An option may be used to hedge risks by allowing parties to agree on a price for a purchase or sale of another instrument that will take place at a later time. One type of option is a call option. A
call option gives the purchaser of the option the right, but not the obligation, to buy a particular asset either at or before a specified later time at a guaranteed price. The guaranteed price is sometimes referred to as the strike or exercise price. Another type of option is a put option. A put option gives the purchaser of the option the right, but not the obligation, to sell a particular asset at a later time at the strike price. In either instance, the seller of the call or put option can be obligated to perform the associated transactions if the purchaser chooses to exercise its option or upon the expiration of the option.

]05] Traders typically use theoretical models to determine the prices at which they will offer to buy and sell options. The theoretical option pricing models often produce values that reflect an option's sensitivity to changes in predefined variables. These predefined variables are assigned Greek letters, such as delta, gamma and theta or other predefinitions such as vega. Delta is a measure of the rate of change in an option's theoretical value for a one-unit change in the price of the option's underlying contract.
Thus, delta is the theoretical amount by which the option price can be expected to change for a change in the price of the underlying contract. As such, delta provides a local measure of the equivalent position risk of an option position with respect to a position in the underlying contract. A "50 Delta" option should change its price 50/100, or '.V2 a point, for: a one point move in its underlying contract.

1061 Gamma. is a measure of the:rate.. of change in an option's delta for a one-unit. change in the; price of the; underlying, contract. Gamma expresses, how much the-,option's delta should theoretically change fora one-unit change in the price of the underlying contract.
Theta is a measure of the rate of change in an option's theoretical value for a one-unit change in time to the option's expiration date. Vega is a measure of the rate of change in an option's theoretical value for a one-unit change in the volatility of the underlying contract. Delta, gamma, and vega are the primary risk management measures used by those who trade in options.

1071 A single option order typically identifies the underlying security or 'instrument the expiration date, whether.the. option is a call or;a put, the strike price and other standard order terms (e.g. buy/sell; quantity, account number ctc.). Each time the price of the underlying contract changes or one. of the variables in the trader's theoretical model changes, a trader mayFcancel all of the relevant orders,. recalculate new order prices and transmit new order prices to the trading engine.

1081 Computer implemented systems for trading derivative :products can increase ,a market maker's price exposure. In the open outcry marketplace, a market' maker makes markets in strikes/spreads in a serial process. As a result, the market maker may minimize the risk of having more than one of their prices acted upon simultaneously. In contrast, computer implemented systems allow market makers to provide bid/ask spreads for several strikes and spreads simultaneously. The parallel price exposure in the electronic options marketplace can pose a risk to the.markct maker in that they can quickly accumulate a large risk position before they can cancel/modify their resting orders. This type price exposure is known as in-flight fill risk.

]09] Existing attempts to protect against in-flight fill risks have resulted in reduced market making participation and corresponding detrimental affects on liquidity, trading volume and price discovery.

]10] Therefore, there is a need in the art for systems and methods for improved derivative .product trading that allow traders and exchanges to, protect against risk and also provide credit. control.

SUMMARY
till The' present invention overcomesproblcros.and limitations of the prior art by providing trading ,methods and systems that utilize order risk data provided by traders.
The order risk data includes order risk parameters, such as maximum delta, gamma and/or vega, utilization values for derivative product contracts based on the same underlying product.
A match system may then limit the trader's in-flight fill risks by tracking the trader's current order risk parameter utilization state and analyzing potential trades to determine how those trades will impact the trader's order risk parameter utilization state. The match system may also limit cumulative risks by canceling orders after an order risk parameter utilization state has been exceeded ]12] An embodiment may include a method of processing derivative product orders at a trading engine. The method may include receiving derivative product order risk data including at least one threshold value corresponding' to at least one: order risk-parameter:
An order for a derivative product is received from a 'trader. As used herein "trader"
includes any source for originating an order and is not limited to mean a professional trader. The derivative product order and a trader's current order risk utilization' state are utilized to calculate utilization data. The derivative ,product order is processed in a manner determined by the derivative. product order risk data` and the utilization data.

]13] An additional or alternative method of processing derivative product orders at a trading engine includes receiving derivative product order risk data including at least one threshold value corresponding to at least one order risk parameter. An order for a derivative product is received from a trader. A trader's current order risk parameter utilization value is then determined. The derivative product order is executed when the trader's current order risk parameter utilization value does not exceed the threshold value.

1141 An 'additional or alternative method of managing risks associated with derivative product orders placed at a 'plurality of trading engines includes transmitting, to a, first trading engine first derivative product order risk data, including at least one threshold value corresponding to at, least one order,, risk-,parameter.. Second, derivative product order risk data including at least one threshold value corresponding to the at least one order risk parameter is transmitted to a second trading engine. A trader's current order risk utilization: states at the first trading.: engine and at- the ,second trading. engine w-q determined. The determination may then be, used to. transmit. to- the first.or second trading engine an offset value to adjust the order risk parameter.

1151 A system for monitoring risks associated with orders placed at a plurality of may include a plurality of trading engines each having an order routing mechanism and a credit control module where the credit control module is communicable with each order routing mechanism. In one embodiment, the plurality of trade engines may be located at a front-end, and the credit control module may be located at a back end. In another embodiment, the credit control module may be located on the front-end, the back end (e.g., clearinghouse), or a combination thereof. The credit control module determines the volume of trades from 'the trading. engine and compares that value to the number of trades allocated for the trading engine. If the .volume of trades exceeds the allocated number of trades 'for the trading engine, the user's orders may be 'cancelled.
Additionally or alternatively, if the volume of trades exceeds the allocated number of trades, the credit control module may request a credit increase from another trading engine.

[161 An additional or alternative system for monitoring risks associated with the value of orders placed at a plurality of trading engines may include a plurality of trading engines each having an order routing mechanism and a credit control module where the credit control module is communicable with each order routing mechanism. The credit control module verifies the credit value of the trader to determine the total value, of orders placed by-the trader on each individual trading engine. If the value of orders on a particular trading engine exceeds a predetermined amount of the trader credit value, the .credit control module- can re=route the order routing mechanism to another trading engine within the plurality:

1171 Additional or alternative embodiments;may'bc-partially or wholly implemented on:-a computer-readable medium, for example;;'by storing,.computcr-exccutlable instructions or=;modules,=or by utilizing computer readable data; structures:

1181. Of ' course, 'the methods and systems of the above-referenced embodiments may, also :include other additional elements, steps, computer-executable instructions or computer-readable data structures. In this regard, other embodiments are disclosed and claimed herein as well.

1191 The details of these and other embodiments of the present invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description and drawings and from the claims.

BRIEF DESCRIPTION: OF THE DRAWINGS, 1201 The out ofband'credit control is illustrated byway ofexample and not limited in=the accompanying figures in which like reference numerals indicate similar elements and in which:

,[211. Figure' 1 shows a .' computer' network system that 4may,be` used. to Amp-lement aspects: for out of band credit:cootroL

1221 Figure 2 illustrates -a system .in which traders exchange; .information with a, match system, in accordance with an embodiment for out of band credit control;

[231 Figure 3 illustrates an order risk management module in accordance with an embodiment for out of band credit control;

1241 Figure 4 illustrates a method of processing derivative product orders at a trading engine, in accordance with an embodiment for out of band credit control, 1251 Figure 5 illustrates a variable defined derivative product order in accordance with an embodiment for out of band credit control;

1261 Figurc.6 illustrates a method of processing variable defined derivative product orders by a trading engine computer, in accordance with an embodiment for out of band credit control; and 1271 Figure 7 illustrates a front-end system that may be used to manage,risks associated with derivative- product orders placed at a plurality of trading. engines.

1281. Figure 8 illustrates a system used to manage risks. associated with -the volume of derivative: product orders placed at a plurality of trading engines.

1291. Figure 9 illustrates a system used to manage risks associated- with the`.credit of atrader .placingderivative product orders at aplurality of tradiiig:engines:

DETAILED .DESCRIPTION

1301 Figure 1 depicts. an illustrative-. operating environment that may be used -to. implerricrit ,various aspects of the invention. The operating-environment is only oneexample=of a suitable =operating environment and.is not intended to suggest any limitation as to, the scope of use or functionality of the invention. Aspects of--the present invention are preferably implemented with computing devices and networks for exchanging, transmitting communicating, administering, managing and facilitating trading information including, but not limited to performance bond amount requirements and trading information. An exchange computer system 100 receives market data, analyzes historical data, and calculates various values, e.g., performance bond amounts, in accordance with aspects of the invention.

1311 Exchange computer system 100 maybe implemented with one or more -mainframes, 'gcrvcit, gateways, controllers, desktops or other computers.. The exchange Computer system '100 may include one or more modules, processors, databases, mainframes, desktops, notebooks, tablet PCs, handhelds, personal digital assistants, smartphones, gateways, and/or other components, such as those illustrated in Figure 1.
Moreover, computer system 100 may include one or more processors (e.g., Intel microprocessor, AMD microprocessor, risk processor, etc.) and one or more memories (e.g., solid state, DRAM, SRAM, ROM, Flash, non-volatile memory, hard drive, registers, buffers, etc.) In addition, an electronic trading system 138, such as the Globcx trading system, may be associated with an exchange 100. In such an embodiment, the electronic trading system includes a combination of globally distributed computers, controllers, servers, networks, gateways, routers, databases, memory, and other electronic data processing and routing devices. The trading system may include a trading system interface having devices configured to route incoming messages to an appropriate devices associated with the trading system. The trading system interface may include computers, controllers, networks, gateways, routers and other electronic data processing and routing, devices: Orders .that are placed with or submitted to the trading system are received at the trading system interface. The-'trading -system interfaee'routes` the order to an appropriate device. A trading engine computer system 100 receives orders and transmits market data related to orders and trades to users.

1321 A user database 102 may include information identifying traders' and other users of :exchange computer system 100.; Such information may include user, names and passwords. A trader operating an electronic device (e.g., computer devices 114, 116, 118, 120 and 122) interacting with the exchange 100 may be authenticated against user names and passwords stored in the user database 112. Furthermore, an account data module 104-may-process account-information that may be-used during- trades:
The account information .may be-;specific; to -the particular trader ;(or, user)..
of an . electronic device interacting with the exchange 100.

1331 A match engine module 106 may match bid and offer prices for orders configured in accordance with aspects of the invention. Match engine module 106 may be implemented with software that executes one or more algorithms for matching bids and offers for bundled financial instruments in accordance with aspects of the invention.
The match engine module 106 and trading system interface may be separate and distinct modules or component or may be unitary parts. Match engine module may be configured to match orders submitted to the trading system: The match engine module may match orders according to currently known or later developed trade matching practices and processes. In an-embodiment, bids-and orders are matched on price, on a FIFO basis. The matching algorithm also may match orders on a pro-rata basis or combination of FIFO and pro rata basis. Other processes and/or matching processes may also be employed.

1341 Moreover, a trade database 108 may be included to store historical information .identifying trades and descriptions of trades. In particular, a trade database may store information identifying or associated with the time that an order was executed and the contract price. The trade database 108 may also comprise a storage device configured to store at least part of the orders submitted by electronic devices operated by traders (and/or other users). A confirmation message may be sent when the match engine module 106 finds a match for an order and the order is subsequently executed.
The confirmation message may, in some embodiments, be an e-mail message to a trader, an electronic notification in one of various formats; or any other form df generating 4a notification of an order execution.

1351 Furthermore, an order book module 110 may be included to compute or otherwise determine current bid and offer prices. The order book module 110 may be configured to calculate the price of a financial instrument.

1361 A market data module 1.12 may be included to collect market data and prepare the_ data for transmission to users. In addition, a risk management module 134 may. be included in computer system 100 to compute and determine the amount of risk associated with a financial product or portfolio of financial products. An order processor module 136 may be included to receive data associated with an order for a financial instrument. The module. 136 may decompose delta based and bulk order types for processing by order book module 110 and match engine module. 106. The order processor module 136 may be configured to process the;'data associated with "the orders for financial instruments.

1371 The trading network environment shown in Figure 1 includes computer (ie:, electronic) devices 114, 116, 118, 120 and 122. The computer devices 114, 116, 118, 120 and 122 may include one or more processors, or controllers, that control the overall operation of the computer. The computer devices 1. 14, 116, 118, 120 and 122 may include one or more system buses that connect the processor to one or more components, such as a network card or modem. The computer devices 114, 116, 118, 120 and 122 may also include interface units and drives for reading and writing data or files.
Depending on the type of computer device, a user can interact with .the computer with a keyboard, pointing device, microphone, pen device or other input device. For example the electronic device may be a personal computer, laptop or handheld computer, tablet pc and like computing devices having a user interface. The electronic device may be a dedicated function device such as personal communications device, a portable or desktop telephone, a personal digital assistant ("PDA"), remote control device, personal digital media system and similar electronic devices.

1381 Computer device 114 is~shown directly _connected to exchange computer system 100:
Exchange: computer; system 1.00 and computer device; 1 14 may be-connected via.a Ti line, a common local area network (LAN) or other mechanism for connecting computer devices. Computer device 114 is shown connected to a radio 132. The user of radio 132 may be a trader or exchange employee. The radio user may transmit, orders or other information to a user of computer device 114. The user of computer device 114 may then transmit the trade or other'information to exchange computer system 100.

139] Computer devices 116 and 118 are coupled to a local area network (LAN) 124. LAN
124 may have one or more of the well-known LAN topologies and may use a variety of different protocols, such as Ethernet. Computers 116 and 118 may communicate with each other and other computers and devices connected to LAN 124. Computers and other devices may be connected to LAN 124 via twisted pair wires, coaxial cable, fiber optics or other media. Alternatively, a wireless personal digital assistant device (PDA) 122 may communicate with LAN 124 or the Internet 126 via radio waves. PDA 122 may also communicate with exchangecomputer system 100 via, a conventional wireless hub: 128:. As used herein,. a PDA includes mobile telephones and other.wireless devices tbetconrniunicatewith'a 'network' via radio waves.

1401 Figure l also'shows'LAN 124 connected to the Internet 126. ALAN 124 may include a router to connect LAN 124 to the Internet 126. Computer device 120 is shown connected directly to the Internet 126. The connection may be via a modem, DSL
line, satellite dish or any other device for connecting a computer device to the Internet.

1411 The operations of computer devices and systems shown in figure 1 may be controlled by computer-executable instructions stored on computer-readable storage medium.
Embodiments also may take the form of electronic hardware, computer software, firmware, including object and/or source code, and/or combinations thereof.
Embodiment may be stored on computer-readable media installed on, deployed by, resident on, invoked by and/or used by one or more data processors (e.g:, risk processor), controllers, computers, clients, servers, gateways, networks of computers, and/orany combinations thereof.` The computers, servers, gateways, may have one or more controllers configured to execute instructions embodied as computer software.
For example, computer device 114 may include computer-executable instructions for receiving interest rate and other information from computer system 100 and displaying to a user. In another example, computer device 118 may include computer-executable instructions for receiving market data from computer system 100 and displaying that information to a user. In yet another example, a processor. of computer system 100 may be configured to execute computer-executable instructions that cause the system 100 to calculate a performance bond amount required to balance risk associated with a portfolio.

1421 One or more market makers 130 may maintain a market by providing'bid and offer prices for a derivative or security to exchange computer system 100.. Exchange computer system 100 may also exchange information with other trade engines, such as trade engine 138. One skilled in the art will appreciate that numerous additional computers and systems may be coupled to exchange computer system 100. Such computers and systems may include clearing, regulatory and fee. systems, such as clearinghouse 140. Coupling. can be direct as described: or any other methoddescr bed herein.

(43J A clearinghouse 140 enables an exchange computer system 100:o provide, contracts with a lower likelihood of default than -over-the-counter (OTC)' roducts: A
clearinghouse 140 arranges for transactions to be settled and cleared.
Clearing is the procedure through which a clearinghouse 140 becomes buyer to each seller of a contract (e.g., futures contract, equities, currencies, interest rate products, etc.), and seller to each buyer, and assumes responsibility for protecting buyer and seller from financial loss by assuring performance on each contract. A clearinghouse 140 may settle trading accounts, clear trades, collect and maintain performance bond funds, regulate delivery and report trading data. In some 'scenarios an exchange may' operate its own clearinghouse 140 through a division of the exchange through which all trades made are confirmed, matched, and settled each day until offset or delivered.
Alternatively, one or more other companies may be provided the responsibility of acting as a clearinghouse 140 with the exchange (and possibly other exchanges). An exchange may have one or more .clearinghouses: associated with the exchange. An exchange may offer firms qualified to 'clear trades to. provide a clearinghouse 140 for the exchange computer system 100. In some instances, these clearing members may be designated into different categories based on the type of commodities they can clear and other factors.

[441 The clearinghouse. 140 may establish minimum performance; bond (i:e., margin) requirements for the-. products, it,., handles. A customer. may be requiredto deposit: a performance bond with the clearinghouse 140 (or designated account) for the purpose of insuring the clearinghouse 140 against loss on open positions. The performance bond helps. ensure ~ the financial integrity of brokers,., clearinghouses,: and exchanges as -a whole. If a trader experiences:.a drop in funds below a minimum-requirement, the clearinghouse 140 may issue a margin call. requiring a deposit intothe margin account to restore the trader's equity. A clearinghouse 140 may charge additional performance bond requirements at the clearinghouse's discretion. For example, if a clearinghouse's potential market exposure grows large relative to the financial resources available to support those exposures, the clearinghouse 140 may issue a margin call.

[451 In another embodiment, the clearinghouse 140 may require a larger performance bond based on a credit check (e.g., an analysis of the credit worthiness, such as using a FICOTM or comparable score, in[er alia) of the customer/trader. The credit check may be performed (r c initiated) by a clearinghouse. 1.40'.6t. an exchange 100. In the :example where the clearinghouse 140 performs. the credit check, the clearinghouse 140 may send a message (e.g., enforcement message- to the "exchange' 100. If the-.,credit check indicates that a customer/trader is a high risk, the enforcement message may increase the margin requirements of the customer/trader, or otherwise adjust the capabilities/constraints of the customer/trader commensurate with the higher risk. In the example where the exchange 100 initiates the credit check, the exchange 100 may send _ a. message to one or --more, clearinghouses associated with the exchange 100, to update them on the increascd/decreased risk associated with the.
customer/trader.

1461 In recognition. of the desire to promote. efficient clearing procedures and to focus on the true intermarket risk exposure. of clearinghouses, a. cross-margining system may be used. By combining the positions of jointand affiliated clearinghouses in certain broad-based equity index futures and options into a single portfolio, a single performance bond requirement across all markets may be determined. The cross-margining system may greatly enhance the efficiency and financial integrity of the clearing system.

1471 The principal means by which a clearinghouse 140 mitigates the likelihood of default is through mark-to-market (MTM) adjustments. The clearinghouse 140 derives its financial: stability in large part by. removing debt obligations -among market participants asthey ~occur. `Through-daily MTM adjustments, every contract is debited or credited 'based on that trading session's gains or losses. For example, as prices move for or against a position, funds flow into or out of the trading account. This cash flow is known as settlement variation.

1481 'Of course ,, numerous:additional servers, computers; handheld`-devices, personal; digital assistants, telephones and other devices may also be connected to exchange computer system 100. Moreover, one skilled in the art will appreciate that the topology shown in figure 1 is merely an example and that the components shown in figure 1 may be connected by numerous alternative topologies.

1491 Figure 2 illustrates a system in which traders 202 and 204 exchange information with a match, system 206, in accordance with an embodiment of-the invention. Trader 202 is =shown transmitting as variable defined* derivative product order 208 and order risk data 210 to match system -206. Variable defined derivative product order 208 includes= the identification of a derivative product and a variable order price. Variable defined derivative product orders arc described in greater detail below in connection with figure 3. Order risk data 210 may act as a throttle to limit the number of transactions entered into by trader 202. Order risk data may include maximum and minimum values of delta, gamma and vega to utilize over a given period of time, such as a trading day.
Trader 204 transmits derivative product orders 212 and 216 to match system 206.
Trader may transmit several derivative product orders and may associate order risk data with one or more of the derivative product orders. As shown in order 212, one or more of the orders may include the identification of a hedge transaction.

1501 Match-system 206 may include several modules for determining prices, matching orders and executing transactions. An order book module 218. may be included to maintain a listing of current bid and offer prices. A price calculation module'220 calculates order prices based on price determination variables provided a's part of variable defined derivative product orders. Price calculation module 220 may also calculate order prices 'based on formulas received from traders. For example, derivative product order 208 niay include' a formula that. is -a'function of an underlying contract, delta and gamma.
Price calculation, module 220 may be; configured to calculate an order price every time the price of the underlying contract changes.

1511 Price calculation module 220 may use a default formula with price determination variable values supplied by a trader. In one embodiment, the change in a derivative product price is equal to a second order Taylor series expansion, such as:

ChgunderlyingPrice*delta+(I /2(ChgUnderlyin9Price^2*gamma))' (l ) wherein ChgUndcrlyingPrice is the change in the underlying price. Trader may supply price determination variables delta and gamma and price calculation module would track the derivative product price as the underlying contract changes.

1521 A formula, database.' 224 may be included to store, derivative product.
order, formulas:
The formulas may be provided by traders or maybe standard formulas provided.by an exchange. A market data module 226 may Wised -to collect and disseminate market data. A match engine module 228 matches bid and offer prices. Match engine module 228 may be implemented with software that executes one or more algorithms for matching bids and offers.

1531 . A hedge module 230 may be included to perform hedge transactions- based on derivative product transactions. In one embodiment of the invention, hedge module 230 conducts transactions with a trading engine or match system other than match system 206. Hedge module 230 may also perform some or all of the function of risk management module 134 (shown in figure 1). Exemplary hedge transactions are described in detail below with references to figures 6 and 7.

1541 An order processing module 236 may be included to decompose variable defined derivative product and bulk order types for processing by order book module 218 and match engine module 228. A controller 232 may be included to control the overall operation of the components shown coupled to bus 234. Controller 232 may be implemented with a central processing unit.

1551 An order risk management module 222 is included to limit as in-flight fill risks. For example, rad'er 202 provided 'maximum and minimum delta, gamma and vega utilization values to match system 206. Those values may be stored in order risk management module 222 and tracked and computed before executing transactions.

1561 Figure 3 illustrates an order risk man=agement module 302. in =accordance' with an embodiment of the invention. A. database X304 stores: order risk parameter settings:
Column '304b, for example, includes delta utilization threshold values. Delta utilization threshold values may be included in order risk data 210 that is transmitted from trader 202 to match-system .206.. Database 304 may also include the current state of order risk parameters. Column;3.04c, for example includes the current delta utilization state for the entities- listed in -column 304a. The current utilization state- of- an order risk parameter is calculated by adding together the utilization values of the order risk parameter from previous trades. For example, if a trader is involved in two trades having individual delta utilization values of +45 and +60, after the second trade is executed, the trader's delta utilization state would be equal to +105.

1571 Database 304 shows an embodiment in which several levels of order risk parameters may be used. For example, firm A has offices X and Y and employs traders 1-4.
Trader I is obligated to comply with the order risk parameters for himself, office X and firm A.. 'Providing -order risk parameter settings,-in a hierarchal mariner-allows entities-to allocate. risks among sub'ordtnate entities 1581 Order risk management module 302 may also include a calculation module 306 for calculate order risk parameter values. An offset module 308 may be used to process offset values received from traders. An offset value may be used to provide an adjustment to an order risk parameter threshold value. For example, firm A can increase its delta utilization threshold to 220 by providing an offset value of 20. In one embodiment of the invention, an entity may allow subordinate entities to provide offset values and place limits on the use of offsets. Match system 206 may also be configured to regulate the use of offsets.

1591 Figure 4 illustratesa method of processing derivative product . orders.
at a trading engine, in accordance with an embodiment of the invention. In step 402 a .matching system receives derivative product order risk data including at least. one threshold value corresponding to lease one order risk parameter. Step 402 may include receiving order .risk data 210. Next, the match system receives an order for a derivative product from a trader in step 404. Step 404 may include receiving a variable defined derivative product order, as has been described above. In step 406, the match system utilizes the derivative product order and a trader's current order risk utilization state to calculate utilization data. In some embodiments, step 406 may include applying the utilization of a hedge transaction that accompanies a derivative product order so that the utilization data accounts for.the hedge transaction. Of course, when the trader is :a subordinate -entity, step 406 may include utilizing the current order risk utilization state of one or more additional entities. For example, with respect to Figure 3, when analyzing trader l's current utilization state, the utilization states of office X and firm A
should also be analyzed. This is because trader 1 may be below his utilization threshold, but office X
or firm A may be over the relevant utilization threshold.

1601 In step 408 the derivative product order is processed in a manner determined by the derivative product order risk data and the utilization data. If the execution of the trade would not cause the resulting utilization data to exceed the relevant utilization ;threshold,. the trade is executed.. There are 'several,altematives, for treating-.orders that ,would cause the utilization data to excecd'a relevant utilization threshold value. In a first embodiment, a portion of the derivative product order is executed. The portion includes the maximum number of contracts that do not cause the utilization data to exceed the threshold value. In an additional or alternative embodiment, a portion of the order that includes the minimum number of contracts that cause the utilization data to exceed the threshold value is executed. In still an additional or alternative embodiment, the entire order is fully actionable,. even if filling the smallest portion of the. order exceeds the risk limits.. For example, if four contracts would not cause the.
utilization data to exceed the threshold value and five contracts would, five contracts are executed.
Of course other embodiments may involve other trading units. For example, if a contract is typically traded in units of 100 contracts, each group of 100 contracts would be treated as a trading unit and treated like the individual contracts discussed above.

(611 In an additional or alternative embodiment an entire order is canceled if the order would result in a trader's order risk utilization state exceeding the threshold value after the trade is executed. For example, if the execution of an order for five contracts would cause the threshold value to :be .exceeded, no contracts are executed.
Additionally or alternatively, a-derivative product;.oider is executed as long as a trader's current order risk utilization state (before execution of the order) does not exceed the threshold value.

1621 In step 410 it is determined whether the trader's order risk utilization state exceeds a threshold value. When. a threshold has been exceeded, some or all of the.
trader's resting orders may be cancelled in step 412. In various, embodiments-:all resting orders or all resting orders within an option class are cancelled. Additionally or alternatively, all risk-increasing orders may be cancelled. For example, if a positive delta limit has been exceeded, then all call bids- and put: offers are cancelled. If a negative delta.liimit has been,exceeded,: then all call offers and put bids are, cancelled, If a positive.,gamma limit has been exceeded, then allcall and-put bids.are cancelled. Likewise, if a-negative gamma limit has been exceeded, all call and put offers are cancelled.

1631 Returning to figure 2, match system 206 may include modules that perform some or all of the functions of the modules shown in figure 1. Moreover, match system 206 may also be coupled to some or all of the elements shown in figure 1. Match system may also be configured to transmit warning messages to traders alerting them of order risk utilization states. Match system 206 may also include or be coupled to an interface that allows traders to check current order risk utilization states via the Internet, another 'network,. telephone,etc.

1641 Figure .5 illustrates a variable'-.defined derivative product order.500 in accordance with an embodiment of the invention. Variable defined derivative product order 500 may include a field 502 for identifying a trader's account number. The underlying contract may be identified in field 504. The expiration month of.the derivative product order may be identified in field 506. The order may be identified as a put or a call in field 508 and whether the order is a buy or sell in field 510. The quantity may be identified in field 512 and the strike price may be identified in field 514. Delta, gamma, and vcga values may be identified in fields 516, 518 and 520 respectively. Of course, other price determination variables may also be. identified as part of a standard variable defined derivative product order..

1651 A hedge transaction may be identified in field 522. The user may choose to make the derivative product order contingent on the existence of an available hedge transaction by selecting, radio button 524. The user may also choose to use best efforts to fill the hedge. order.after the execution of the derivative product order by selecting radio button 526.

1661 The formula for calculating the price of variable defined derivative product order is identified: in field 528. The trader can select a:standard formula 530 to compute their derivative; product price or.select a custom-formula 532. 'In one embodiment,:
a standard formula is supplied by or sponsored by an exchange. When a custom formula is selected, the trader may also provide a formula in field 534 and the variables in field :536., In one implementation of the invention; variable defined derivative productorder 500 is, created in the, form - of an XML for HTML document created by ;one .of ` the 1. 1 computer devices shown in figure 1. Variable defined derivative product order 500 may be encrypted before being transmitted to a trading engine. Of course one or more additional or alternative fields may be included. For example, a reference price may be included to protect against mispricing conditions.

1671 Figure 6 illustrates a computer-implemented method of trading a derivative product contract that involves the use of a variable order price, in accordance with an embodiment of the invention. First, in step 602 it is determined whether the trader desires to use a standard exchange sponsored formula. When the trader uses a custom formula, `the, formula is transmitted to, thcexchange computer in step 604:
Step 604 may also include the trader or exchange transmitting the :formula to other`
Market participants: -In step 606, the trader transmits,price determination variable values for the standard formula to an exchange computer. For example, step 606 may include transmitting delta and gamma values to an exchange computer. Step 606 may also include transmitting a formula and price determination variables to other computers so that other computers may calculate an order book. Additionally or alternatively, the exchange computer .may distribute all :formulas .and price determination variables to user computers. In. step 608 the trader receives underlying data.. The underlying data may include current bid and offer prices for underlying put and call futures contracts.

1681 In step 610 it is determined whether the underlying data has changed. The price of an underlying contract may change multiple times per second. When the underlying contract data has changed, in step 612 the trader's computer device may recalculate the order price of their variable defined derivative product order and all other variable defined derivative product orders from other users based on current data. In step 614, it is determined whether any of the price determination variables used in the formula to calculate the order price have changed. The price determination variables may include delta, gamma, and vega. When the price determination variables have changed, in step 612, the order price is recalculated. Of course, step 612 may be performed based on changes in current underlying contract data and variables. The order price may be displayed to the trader orplotted' n ,a graph that; tracks order prices..

(691 A trading engine computer or match system may..transmit.aplurallty of variable defined derivativeproductorders ao several different .traders: only when othcr-d, q, '' order users establish their initial positions. The cxehangc computer may, then transmit underlying data or other data used to calculate variable defined derivative product order prices. Each trader computer may periodically calculate current order prices based on information received from the exchange computer. For example, in step 616 it is determined whether other variable defined derivative product orders are received.
When variable defined derivative product orders are received, in step 618 the trader computer may calculate new order book listings for current==bids and, offers:
related to variable def ned derivative: product based orders. The order book. may be displayed to the trader in any one of--a variety--of conventional formats, After step- 618, control returns to step 608.

1701 Figure 7 illustrates a front-end system that may be used to manage risks associated with derivative product orders placed at a plurality of exchanges, in accordance with an embodiment of the invention. A front-end order risk module 702 may reside on a terminal connected to one or more trading engines via a network, such as the Internet.
Front-end order risk module 702 may comprise a portion of a software application that allows traders tO intcract.with trading engines. kcalculation module.704.fanctions-in a manner similar to. calculation module 306. Front-end order risk module 702 :allows traders to manage risks associated with testing orders placed at'=a plurality of trading engines. For example, the trader may provide order risk data to trading engines 706 and 708. An order risk data database 710 may be included to calculate and track order risk data that has been provided to trading engine 706 and trading engine 708.

1711 An offset module 712 may be used to distribute risks among two or more trading engines. For example, the current :utilization of an order risk parameter at trading engine 706 is equal to the utilization threshold. As a result, no additional contracts will be executed at trading engine 706. However, the current utilization of the order risk parameter at trading engine 708 is below the utilization threshold. Based on this information, offset module 712 may transmit offset value 714 to trading engine 706 to allow trading engine 706 to execute additional contracts. The use of offset 714 allows the trader to continue conducting transactions while ensuring that, the combined utilization threshold is notexcecded. The front-end order risk module 702 may prompt the trader to enter offset values. Additionally or alternatively, offset module 712 includes computer-executable instructions that generate offset values to transmit to trading engines based on the current utilization at the relevant trading engines.

1721 In a distributed trading environment, there is a "many-to-many"
relationship between the number of traders and the number of trading engines being traded on. Each trading engine has a particular capacity of trades that it is able to process, depending on a number of factors, including space and connectivity. In this relationship, there is a routing: mechanism -to'deliver, trades to -the correct engine, but there is typically limited to; no communication between engines'to'confirm what the trader maybe doing in other markets 'and utilizing other trading engines. 'It-M also contemplated, however, hatthe individual trading engines are not required to check with the credit control module to determine that the user does not exceed the user's available credit. In this way, credit aggregation may be performed out-of-band, with communication back to each of the trading engines that allow for enforcement of controls in-line to the trading activity.
Thus, each. trading engine may act , on its own , to determine whether. the trader, is engaging in proper trading activity. Additionally or alternatively, each of'the trading engines may communicate with each other utilizing another module (besides the credit control module) to make determinations as to the trading activity.

1731 Embodiments in accordance with the present invention provide credit control monitoring across any number of engine instances without adding or introducing significant performance or scalability limitations. A credit control module may provide asynchronous monitoring (e.g., out of band) and management of credit controls with :communication --back to the order routing mechanism or trading engine to confirm curretit thresholds, any credit control events or other in-line controls.

1741 Credit control events include events that are, related 'to, risk paramcters.Wand can be, asynchronous (e.g., out-of-band) or in line (e.g., in-band). Credit control events may include characteristics associated with an order,. such: as contract terms;
number .of trades, types of options,. number of contracts time order is placed,'value:of order-andõso on. Credit control events may also include characteristics associated with derivative risk parameters, such as delta, gamma and vega. In addition, credit control events may be based on-properties of the contract; for, example, a short term: versus a ;long term contract `It is=contemplated that: credit control events ;can be based on any of the; above or- any combination of the=above: ' Ifis: further contemplated thata credit:control:module in accordance with the present invention may provide other in-line controls, such as the delta value of the aggregate trading.

1751 Credit control events. may, include gross or net risk parameters and limits; therein. For example, there-.are those orders which may add' risk, to 'a.trader's portfolio or subtract risk from the trader's portfolio. A trader's gross trading may be calculated by aggregating the number of contracts. If a trader were to place five different orders for five contracts each, the gross of the trader would be twenty-five. In contrast, it is contemplated that certain orders may subtract risk from the gross aii ount: If a trader were to place two different orders. to buy five contracts and two different orders to sell five, contracts (assuming that. a sell order in this instance reduces risk),.the''tradcr's:net risk parameter would be zero. Along these lines, the credit control events may be based off of other notional values, such as positions held or a profit versus loss analysis of a portfolio. By measuring these notional values, the overall risk parameter of the portfolio or the profit/loss of a position can be evaluated. Thus, it is contemplated that 'the ,` risk- parameters .for use with the present invention can be customized for.,ieach-trader nor trading engine:

1761 In an asynchronous credit control, extensions are. provided to provide limited in-line processing in the order routing mechanism or trading engine. Preferably, a maximum quantity definition is managed-in the credit control component and communicated back to the order routing mechanism and trading engine components. The maximum quantity definition can be set to a maximum allowable credit value and is preferably modifiable.by'a.firm or credit 'control module in order to reduce the maximum quantity that can be traded as the credit control limit is approached. As explained herein, it is contemplated that the maximum quantity definition is also applicable to the in-line credit control.

1771 It is contemplated that once a pre-determined capacity of:trading has been reachedõ the credit control module may cancel any risk increasing or remaining orders.
Additionally or alternatively, once a pre-determined capacity of trading has been reached, the credit ;control module; may request >. an. increase in. credit- available from the order ;routing mechanism of one trading engine : to -the order routing mechanism :of a second trading engine. In this way the credit control module manages the numbcr -of trades to-'ensure that the maximum allowable credit value is not exceeded. Furthermore, it is contemplated that the limiting or canceling of orders may be accomplished = in the direction of the risk, so as to minimize risk where possible.

(781 As explained herein, each trader has associated with that trader a specific amount of credit. It is contemplated that as used herein, the term trader applies to individuals, brokerage houses and other investment firms as well as computer generated orders or automated orders. It is contemplated that the term a trader as used herein can be any source that originates an order.

1791 As=shown in Figure 8, an asynchronous embodiment in accordancc.'with the teachings of the present invention is shown. In the asynchronous system 800, the credit control module 802, which is executing on a processor of a computing device, monitors the current thresholds. The threshold may be monitored to ensure that a maximum number of orders and trades are not exceeded by a trading engine 804. The credit control module 802 may receive a feed (e.g., near realtime or realtime) with trade and/or order information associated with one or more exchanges. The credit control module may use this out-of-band information to generate an enforcement message. The out-of-band information is useful to manage the credit associated with a submitted order.

1801 It is contemplated that the credit control module 802 may be located in any of numerous locations. In one embodiment, the credit control module 802 may be located on the front end (e.g., at a trader's 806 terminal). In another embodiment, the:
credit control module 802 may be located on the back end (e.g., clearinghouse 140 or clearing firm site). It is further contemplated that the credit control module 802 may be a unitary part of the match system 814. For example, the credit control module 802 may be a part of the match system 814 to process the trade order that is placed. A trader 806 places a trade through the trading engine 804, which relays the trade through the order routing mechanism 808 to an interface at the match system 814 or credit control module 802 to receive the order. The credit control module 802 relays information regarding the trader 806 and identifies` which trading engine 804 the trade is being ;
placed`through.

1811 Each trading- engine 80.4 also may include information that is:
associated with that trading engine?804. For example, each. trading; engine 804 may include information 'about the locationof the engine, the trading history of the engine, an index of derivative products traded, and/or a trading volume capacity, etc. The trading engine 804 may include information regarding the maximum number of trades, or trading capacity, that the engine is capable of handling. This information can be communicated to the credit control module 802 through the order routing mechanism 808 at anytime during the process of placing the trade: before, during or after. In one embodiment, the credit control modulc..902' may receive this information and process it before.
execution of the .:order is permitted. In.,an alternate embodiment, this information maybe=.communicated anytime during the process of placing the trade. The credit control module 802 may determine the number and value of trades each trading engine 804 is attempting to place while the trades are being placed. At the same time, the credit control module 802 is communicating with the order routing mechanism 808 and may determine the trading volume capacity of the trading engine 804.

1821 If the number-and/or value of trades being placed through the order routing mechanism 808 exceeds the maximum trading, volume capacity, the credit control module 802 can request a credit. increase for the trades from another trading engine. :804' via another order routing mechanism 808'. It is .contemplated that the credit control module 802 will begin to request an increase in credit from another trading engine once a certain percentage of the maximum trading volume is being approached. In one example, if the amount of trades reaches 98% of the maximum trading volume of the trading engine 804, the credit control module 802 will begin to request credit from the order routing mechanism 808 of one trading engine 804 to the order routing mechanism 808' of a another trading engine 804'. Those of ordinary skill would appreciate the pre-detcrmined level to begin requesting credit from one trading engine to another.

1831 Additionally or alternatively, when the credit control module 802 requests a credit increase to a second trading engine due to the over-capacity of a first trading engine, the maximum trading value capacity of the second trading engine is=checked. `.
Should, the second ,trading engine also be at a pre-determined level of the maximum trading value of the second trading engine, the credit control module 802 may request an increase in credit from a third trading engine. It is contemplated that each trading engine may have differentmaximum-trading value capacities;. although: some:, or. all. may-:have, the,.same.
In this way, the credit control module 802. will continue7to request a.credit.
increase from 'a first trading engine until a trading engine is reached that is not at the'pre-determined level of maximum trading value capacity and then the trade can be placed through the order routing mechanism of that trading engine.

1841 In another embodiment in accordance with the present invention, a. credit control module provides monitoring andmanagcment of credit controls with communication to each trading engine to act as a bank to manage the available credit. In this way, the credit controls can be managed in-line with the credit control module, which can manage where to add or subtract credit.

1851 As, shown in Figure 9, an, embodiment illustrating, how ',a credit control ;module can 'provide:monitoring;and management to act as a bank : to: manage available credit that is provided. This embodiment of the invention shows a banking system 900 wherein the credit control module 902 monitors and manages the credit capacity of a trader 904.
The trader 904 places a desired trade order on the front-end of the system. In particular, the trader 904 interacts with a trading engine 908 to place a desired trade.
The trade information for the desired trade is then sent to the order routing mechanism 910, which in turn communicates the trade information from the front-end to the trade match module 914. The trade match module 914 may be located at the back end (e.g., 'clearinghouse 140), front-end, a combination thereof, or another location.
The trade information is. sent through an interface to the trade match module 914 to, the, credit control module 902. The trade is not placed into- the trade match- module 914 until provided acceptance from the credit control module 902.

1861 Furthermore, the credit control module 902 may receive, in some embodiments in accordance with aspects of the disclosure, a near real-time Iced of outbound data. The outbound data may include, among other things, copies of orders and trades being executed. The outbound data may be sent out-of-band to prevent bandwidth/latency issues with in-band data, and to avoid interruptions of order flow. The out-of-band feed may be used by the credit control module 902 to process risk in a near real-time manner to track trading activity (e.g., by a trader 904 using a trading engine 908).
The credit control module 902 may aggregate data from one or more: exchanges. and/or clearinghouses and be able to provide a more robust monitoring. In an alternate embodiment, aggregation may be performed out-of-band, with communication back to each of the trading engines. Thus, each trading engine 904 may act on its own to communicate with each other, independent of a credit control module 902, to determine whether the trader is engaging in proper trading activity. The out-of-band aggregation may occur at the backend (e.g., clearinghouse 140), at the exchange 100, or a different .location (e.g.; bya thiid-partyentity responsible for aggfegatiorr and/or'distribution).

1871 The credit control. module.902 may implement one 'or more business rules based on predefined thresholds or tolerances. of- risk. For example, when SPAN
portfolio risk exceeds. a limit, the credit control module 902, may take action to, reduce.
risk. In another-example; if the true profitandJoss, monitoring detects that a trader has'lost more than a particular amount of money, then an enforcement message may be sent to reduce risk. In yet another example, the credit control module 902 may send an enforcement message if a certain amount of delta is exceeded. That enforcement message may indicate that options trading is cutoff.

1881. The credit control module 902, with assistance from .a number of other modules, may generate an enforcement message for transmission to a clearinghouse 140 or exchange computer system. 100', as. explained above. The enforcement message may cause.
the clearinghouse 140 or exchange computer system 100 to prevent further trading, by a particular trader 904 and/or trading engine 908. The enforcement message may halt trading of a particular product or by particular traders by, inter alia, sending an enforcement message defining a maximum clip size (i.e., maximum number of lots to be traded) of zero, thus, cutting off trading. In other embodiments in accordance with aspects of the disclosure, the maximum clip size may be set to values other than zero (e.g., 1, 10, 50, 100, etc) In some embodiments, other values may be set for bids or offers to prevent accumulating. risk in one direction while allowing orders and/or trades that reduce risk.

1891 In some embodiments, the risk may be calculated based on a specific product or aggregated across products for a specific, trader 904, group of "traders (e.g., all., traders at a particular division of a trading firm), or a trading-firm. For example , a.
product.-may, be defined, in some examples, by a specific contract and/or maturity group, group of contracts, generic products, asset classes, exchange, or other characteristic.
Meanwhile, entities (c g., groups of-traders; iirms,=.etc) may be; defined by account number, specific trader ,-firm, trading connection, or other characteristicõ The ; enforcement-message may be customized to:indicate specifically what product or entity will operate under reduced or halted trading. At least one benefit of such customization is that the credit control module 902 may more precisely restrict trading when a risk has been identified. In some embodiments, a single enforcement message may include multiple separate enforcement messages. For example, a batch enforcement message may halt bids for particular products and also reduce trading for a particular entity.

1901 Each trader -904 has 'associated with it. trader. information.. Included 'in the trader .information is a total credit parameter which may include a maximum :credit value.
Once `the order is'sent from the trader 904 on :the front-end, the credit control module 902 reviews. the maximum credit value for the trader 904. If the value of the desired trade being placed is less than the maximum credit value associated with the--trader, the credit control module 902 will allow the trade to proceed to the trade match module 914 for execution. If, on the other hand, the value of the desired trade being placed is greater than the maximum credit value associated with the trader 904, then the credit control module 902 can stop the trade from execution by not allowing the trade to proceed to the'trade match module 914.

1911 In addition, the credit control module 902 can stop a particular trade from being executed if it is approaching the traders 904 maximum credit value. If the trader 904 has attained a certain (typically predetermined) percentage of his/her maximum credit value; the credit control module 902 can stop the trade from being executed.
Alternatively, the credit control module 902 can send an alert to the trader 904, informing. the -trader 904 that the maximum credit value is approaching. Still alternatively, the credit control module 904 may do any combination of allowing the trade to proceed to the trade match module 914, halting the trade and alerting the trader.

1921 The credit control module may also or alternatively monitor the number of trades of .each: trading.engine ;and- also, act as a bank . and manage the credit of a =trader; as described above. Inrcertain embodiments, ifa'trader places a trade through the trading engine, the credit control module will check to make sure that trader has enough available credit to make the trade and also that the trading engine has the capacity to fill the requested' volume of'the trade. If the fraddcr hasfenough.crcditbut'thetrading engine does : not have the -volume.; capacitythe credit;,control,`module-Ie9uests- i credit increase for the trading engine `by requesting-a credit increase, (from the' available=-credit of another trading engine as described above.

1931 Embodiments of the present invention can be extended for any market, future, option, forward or other financial instrument or investment vehicle with a defined set of weights or conversion rules to compare all traded contracts against a set of user defined values. It is contemplated that financial instruments and investment vehicles herein are interrelated. For example, it is contemplated that a trader may trade a future, followed by an option on that future. Such a position is known as hedging.
Alternatively and additionally, it' is contemplated' that traders may use equities and currency in a risk offsetting manner as would be appreciated by those in the art. Other examplcs,include incidents such:as a stock and an.index. These valuescanbe defined statically or can`be defined dynamically-on a- relative basis for time or even volatility. This can also be applied with a user defined set of models or relationships between contracts or asset clauses.

[941 The present invention has been described herein with reference to specific exemplary embodiments thereof. It will be apparent to those skilled in the art, that a person understanding this invention may conceive of changes or other embodiments or variations, which utilize the principles of this invention without departing from the broader spirit and scope, of the invention as set forth in the appended-claims. All are considered within thc,sphere, spirit, and scope of the invention. For-example, aspects of the invention are not limit to implementations that involve the trading of derivative products. Those skilled-in the art will appreciate that aspects of the invention may be used.in other markets. Credit markettiansactions, for example, involve risk parameters in, the form "of duration risk;and-default risks. The processing of appropriate orders in credit markets may include analyzing duration risk utilization and default risk utilization.

Claims (30)

1. A system for monitoring risks associated with orders placed at a plurality of trading engines, the system including:

an interface to a plurality of trading engines, each trading engine including an order routing mechanism and a total credit parameter associated with a maximum aggregate risk parameter for the trading engine;

at least one credit control module communicable with the plurality of trading engines, the credit control module receiving orders and communicating a quantity definition of the trading engine to determine the value of orders placed on each individual trading engine;
wherein if the value of orders exceeds a predetermined amount of the quantity definition, the credit control module requests an increase in credit from the order routing mechanism to another trading engine within the plurality of trading engines.

2. The system of claim 1, where the at least one credit control module is part of a match system, where the match system is configured to match the orders and execute transactions.

3. The system of claim 1, further comprising:

a match system of an exchange communicable with the plurality of trading engines and the at least one credit control module, where the credit control module is located outside of the exchange.

4. The system of claim 1, where the at least one credit control module is located at a front-end that includes the trading engine.

5. The system of claim 1 where the quantity definition comprises a credit parameter.

6. The system of claim 1 where the credit control module evaluates the credit parameter through the order routing mechanism.

7. The system of claim 6 where the placed order is executed in response to a determination that the credit parameter is safe.

8. The system of claim 6 where the placed order is canceled in response to a determination that the credit parameter is over.

9. The system of claim 6 where the trading engine requests an increase in credit from a second trading engine in response to a determination that the credit parameter is approaching,

10. The system of claim 9 where the credit control module determines the quantity definition of the second trading engine.

11. The system of claim 10 where the second trading engine transfers credit for the execution of the placed order at the first trading engine in response to a determination that the credit parameter for the second trading engine is safe.

12. The system of claim 10 where the second trading engine cancels the placed order at the first trading engine in response to a determination that the credit parameter for the second trading engine is over.

13. The system of claim 10 where the second trading engine requests a credit increase from a third trading engine in response to a determination that the credit parameter for the second trading engine is approaching, and where if the credit parameter for a third trading engine is over, the credit control module requests a credit increase utilizing the order routing mechanism of the third trading engine to a next trading engine within the plurality until a trading engine is located where the credit parameter is not over.

14. The system of claim 1 where the credit control module performs a credit check and sends an enforcement message to an exchange indicating results of the credit check, where the exchange is communicable with the credit control module, and the credit control module is located outside of the exchange.

15. The system of claim 1, wherein the plurality of trading engines are configured to receive orders, for derivative products.

16. The system of claim 1, where the at least one credit control module further communicates an enforcement message to the plurality of trading engines, where each of the plurality of trading engines are configured to reduce further trading using the trading engine based on the enforcement message.

17. The system of claim 16, where the enforcement message identifies at least one of: a particular trader for whom all trading is halted and a particular product for which all trading is halted.

18. The system of claim 16, where the enforcement message is a batch enforcement message.

19. A method of managing credit, which is associated with derivative product orders placed at a plurality of trading engines, using a credit control module of a clearinghouse that is executing on a processor of a computer, the method comprising:

prior to an electronic match system executing an order, determining, using the credit control module, an aggregate risk parameter for each trading engine; where the aggregate risk parameter includes a total credit parameter, where said total credit parameter is the maximum value of orders that can be placed through that trading engine;

assessing, using the credit control module, the value of orders placed at each trading engine; and comparing, using the credit control module, the value of orders placed at each trading engine with the aggregate risk parameter for each trading engine; where if the value of orders being placed at each trading engine is less than the aggregate risk parameter for that trading engine, each order is executed by the match system; further where if the value of orders being placed at each trading engine is greater than or equal to the aggregate risk parameter for that trading engine, each order is canceled; and further where if the value of orders being placed at each trading engine is approaching the aggregate risk parameter for that trading engine, a request for a credit increase is made to another trading engine with an appropriate aggregate risk parameter.

20. The method of claim 19, where the computer executing the credit control module is at a clearinghouse.

21. The method of claim 19, where the trading engine is executing on the same computer executing the credit control module.

22. The method of claim 19 where the aggregate risk parameter also includes a maximum allowable-credit value for each trader for all of the plurality of trading engines.

23. The method of claim 19 where the credit control module determines the total value of orders being placed by a trader for all of the plurality of trading engines.

24. The method of claim 23 where the credit control module compares the value of the total number of orders for each trader with the maximum credit value for that trader; where if the value of orders being placed by the trader at all trading engines is less than the maximum credit value for that trader, each order is executed; further where if the value of orders being placed at each exchange is greater than or equal to the maximum credit value for that trader, sending an enforcement message directing cancellation of each order, and further where if the value of orders being placed at each trading,engine is approaching the maximum credit value for that trader, additional credit value is requested from another trading engine.

25. The method of claim 19 where the value of orders is approaching the aggregate risk parameter when a predetermined value of orders of the aggregate risk parameter is reached, and wherein the order includes a derivative product order.

26. A method for managing credit associated with at least one order submitted using one of a plurality of trading engines, the method comprising:

receiving out-of-band information related to at least one order associated with a trading engine, where the information includes an aggregate risk parameter having a total credit value maximum and a near real-time feed of outbound data of an exchange;

verifying that a total credit value for the trading engine is less than the aggregate risk parameter of the trading engine; and sending an enforcement message, whereby if the total credit value is more than the aggregate risk parameter of the trading engine, the enforcement message requests a credit value increase for the trading engine from a second trading engine.

27. The method of claim 26 where as the total credit value of the trader approaches the aggregate risk parameter, a risk security measure is implemented using the enforcement message.

28. The method of claim 27 where the risk security measure is selected from one or more of cancelling the order; requesting a credit value increase notifying the trader; executing the order and executing a portion of the order.

29. The method of claim 26, wherein the at least one order comprises a derivative product order.

30. The method of claim 26, wherein the order comprises a derivative product order: