WO2006002294A2 - Methods and apparatus for online foreign currency exchange - Google Patents

Methods and apparatus for online foreign currency exchange Download PDF

Info

Publication number
WO2006002294A2
WO2006002294A2 PCT/US2005/022187 US2005022187W WO2006002294A2 WO 2006002294 A2 WO2006002294 A2 WO 2006002294A2 US 2005022187 W US2005022187 W US 2005022187W WO 2006002294 A2 WO2006002294 A2 WO 2006002294A2
Authority
WO
WIPO (PCT)
Prior art keywords
price
order
settlement date
bids
bid
Prior art date
Application number
PCT/US2005/022187
Other languages
French (fr)
Other versions
WO2006002294A3 (en
Inventor
Eric Hirschhorn
Chris Carrol
Arvind Narayan
David Tazartes
Brian Bernstein
Original Assignee
Eric Hirschhorn
Chris Carrol
Arvind Narayan
David Tazartes
Brian Bernstein
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Eric Hirschhorn, Chris Carrol, Arvind Narayan, David Tazartes, Brian Bernstein filed Critical Eric Hirschhorn
Publication of WO2006002294A2 publication Critical patent/WO2006002294A2/en
Publication of WO2006002294A3 publication Critical patent/WO2006002294A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Definitions

  • This invention relates to the field of currency trading.
  • SUMMARY Objects of the invention comprise: (1) address limited price transparency; (2) address the market share domination held by the major banks; (3) address the failed competitive efforts of the past; and (4) address the cost problem associated with currency transactions.
  • Various aspects of the invention address these issues.
  • the software implementation of the present invention provides more price transparency to market action than previous systems; the non-deliverable forward aspect of the invention addresses the settlement cost issue; and the open-to-all-participants aspect of the invention addresses the l-NY/1922896.1 1 oligopoly and profit structure issues.
  • the invention comprises a non- deliverable currency system open to all market participants with full market depth.
  • Appendix A which is directed to bot aspects of the present invention
  • Appendix B which is directed to matching engine aspects.
  • One aspect of the present invention is directed to providing a user with stack displayed data regarding bid and offer prices, and stack displayed data regarding the number of bidders and offerers at a particular price.
  • Such information can be presented to a user in graphical form (e.g., in a table with columns and rows) and all such data can be presented to a user simultaneously.
  • the 10 highest bids and 10 highest offers can be presented to a user.
  • This additional price and quantity data may enables a user to better gauge which bid or offer is appropriate for a particular trading goal. For example, and by way of comparison, a user viewing a system that only indicates 1 bid is at a disadvantage with respect to someone with the same trading goal presented with additional bid and offer data. Such disadvantage may force a user to speculate as to other bids, and cause the user to bid at a price higher than necessary in order to complete a transaction.
  • Such bidding may, in effect, reduce the profitability of their trades.
  • Another aspect of the present invention is directed to providing a user with the ability to roll executed currency trades from one settlement date to another settlement date. For example, where a user has bought a product that is to mature in one day, but does not wish for that product to mature, the user may roll the current contract to a later settlement date.
  • a roll transaction allows a user to roll a trade from one settlement date to another settlement date without having to book a buy and a sell.
  • a match engine is a message oriented, single threaded application that performs matching and automated market making based on specified rules.
  • the functions performed by the match engine include: accepting incoming orders with quantity, price, and sender information; and performing market actions on the order (for example, inserting an order into an order book or canceling an existing order); and producing reports as confirmation of market actions: (for example, fill, partial fill, new order, cancel, etc).
  • 1 -NY/1922896.1 2 matching is done on a price-time priority basis. In an embodiment, if an incoming order has a corresponding matching order, it is matched instantly.
  • the present invention is directed to a computer-implemented method for currency exchange comprising electronically receiving data regarding a first plurality of currency bids and a first plurality of currency offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of bids and said first plurality of offers are associated with a first settlement date; electronically receiving data regarding a second plurality of currency bids and a second plurality of currency offers, said data comprising prices and quantities for said second plurality of bids and said second plurality of offers, wherein said second plurality of bids and said second plurality of offers are associated with a second settlement date; displaying said first plurality of bids and said first plurality of offers in a first arrangement corresponding to said first settlement date and displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers; and displaying said second plurality of bids and said second plurality of offers in a second arrangement corresponding to said second settlement date and displaying at least some
  • said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for displaying offers corresponding to said first settlement date
  • said second arrangement comprises a third column for displaying bids corresponding to said second settlement date and a fourth column for displaying offers corresponding to said second settlement date.
  • the present invention is directed to a computerized system for currency exchange comprising a communication component operable to receive currency exchange data regarding bids and offers for a first settlement date and a second settlement date; a display component operable to display said currency exchange data for said first settlement date in an arrangement corresponding to said first settlement date, and said currency exchange data for said second settlement date in an arrangement corresponding to said second settlement date, wherein said first arrangement and said second arrangement are displayed simultaneously to a user.
  • said currency exchange data regarding bids and offers for 1 -NY/1922896.1 3 said first settlement date comprises a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity
  • said currency exchange data regarding bids and offers for said second settlement date comprises a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity
  • said currency exchange data for said first settlement date is displayed in a first arrangement corresponding to said first settlement date, said first arrangement displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers, and said currency exchange data for said second settlement date is displayed in a second arrangement corresponding to said second settlement date, said second arrangement displaying at least some of said prices and quantities for said second plurality of bids and said second plurality of offers
  • said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for
  • system further comprises a matching component operable to match at least one bid and at least one offer related to a particular settlement date; and a rolling component operable to roll one or more currency exchange trades from said first settlement date to said second settlement date.
  • the present invention is directed to a computer-implemented method for foreign currency exchange comprising electronically receiving data regarding a first plurality of roll bids and a first plurality of roll offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of roll
  • 1 -NY/1922896.1 4 bids are associated with a first settlement date, and said first plurality of roll offers are associated with a second settlement date; displaying said first plurality of roll bids in a first arrangement corresponding to said first settlement date and at least one of price and quantity; displaying said first plurality of roll offers in a second arrangement corresponding to said second settlement date and at least one of price and quantity; and rolling a currency exchange trade from said first settlement date to said second settlement.
  • rolling a currency exchange trade from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date.
  • the present invention is directed to a system for foreign currency exchange comprising a communication component operable to receive currency exchange data regarding one or more roll bids for a first settlement date and one or more roll offers for a second settlement date, wherein each of said one or more roll bids corresponds to a distinct currency trade, and each of said one or more roll offers corresponds to a distinct currency trade; a display component operable to display said one or more roll bids in an arrangement corresponding to said first settlement date and at least one of price and quantity, and said one or more roll offers in an arrangement corresponding to said second settlement date and at least one of price and quantity; and a rolling component operable to roll a currency exchange trade from said first settlement date to said second settlement date.
  • said one or more roll bids each comprises a roll bid price and a roll bid quantity
  • said one or more roll offers each comprise a roll offer price and a roll offer quantity
  • a currency exchange trade rolled from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date.
  • Fig. 1 depicts aspects of a foreign exchange currency trading system in accordance with an embodiment of the present invention
  • FIG. 2 depicts further aspects of the system of Fig. 1;
  • Fig. 3 illustrates an exemplary price monitor display suitable for use in conjunction with an embodiment of the present invention
  • Fig. 4 depicts a trade blotter display in accordance with an embodiment of the present invention
  • Fig. 5 depicts a stack view display in accordance with a preferred embodiment of the present invention
  • Fig. 6 depicts an order ticket display for
  • Fig. 7 depicts an account summary display
  • Fig. 8 depicts an account detail display for an exemplary account
  • Fig. 9 depicts an exemplary query trade history display
  • Fig. 10 depicts an exemplary query fixing history display
  • Fig. 11 depicts an exemplary customer information display
  • Fig. 12 is an exemplary list of accounts display
  • Fig. 13 is an exemplary account detail display
  • Fig. 14 is an exemplary settling position breakdown display
  • Fig. 15 is an exemplary trade detail display
  • Fig. 16 is a composite block/flow diagram of an embodiment of the present invention
  • Fig. 17 is a flow diagram illustrating preferred processing of a foreign currency exchange order
  • Fig. 18 depicts screen shots corresponding to the steps of Fig. 17;
  • Fig. 19 depicts additional screen shots corresponding to the steps of Fig. 17;
  • Fig. 20 is a flow diagram illustrating preferred operation of a roll trade
  • Fig. 21 illustrates price filter inputs, intermediate calculations and outputs
  • Fig. 22 illustrates an embodiment for the calculation of a radius
  • Fig. 23 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market
  • Fig. 24 illustrates a bot responsible for executing partial arbitrage orders that keep 1 -NY/1922896.! g certain non-deliverable markets in line with the DAR deliverable market
  • Fig. 25 illustrates a process flow for the bot illustrated in FIGURE 24
  • Fig. 26 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market
  • FIG. 27 illustrates a bot responsible for executing partial arbitrage orders that keep certain non-deliverable markets in line with the DAR deliverable market;
  • Fig. 28 illusrates a BotlOX responsible for executing cash to roll arbitrage orders;
  • Fig. 29 illustrates a process flow for BotlOX;
  • Fig. 30 illustrates a type 1 arbitrage;
  • Fig. 31 illustrates a type 2 arbitrage;
  • Fig. 32 illustrates the processing Flow for Botl20;
  • Fig. 33 illstrates the notional stacks of Bot20;
  • Fig. 34 illustrates an embodiment for protecting against pick-offs on bids in the stack;
  • Fig. 35 illustrates an embodiment for protecting against pick-offs on asks in the stack;
  • each stack can have a target distribution
  • Fig. 37 illustrates an embodiment for protecting against pick-offs on bids in the stack
  • Fig. 38 illustrates and embodiment for protecting against pick-offs on asks in the stack
  • Fig. 39 illustrates the operation of an embodiment of Bot22
  • Fig. 40 illustrates thresholds and parameters as described in connection with Bot22
  • Fig. 41 illustrates the flow of an embodiment of Bot22
  • Fig. 42 illustrates a type 1 arbitrage
  • Fig. 43 illustrates a type 2 arbitrage
  • Fig. 44 illustrates an embodiment of the processing flow for Bot3X
  • Fig. 45 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market
  • 1-NY/192 2 896.I J Fig. 46 illustrates a process flow for the bot illustrated in Figure 45;
  • Fig. 47 illustrates an embodiment for the flow of Bot40
  • Fig. 48 illustrates a network diagram for Bot41
  • Fig. 49 illustrates a network diagram for Bot41
  • Fig. 50 illustrates an embodiment for setting the parameters for "SpeedOrderSize" as controlled by the timers for Bot42;
  • Fig. 51 illustrates an embodiment for the processing flow for Bot4X
  • Fig. 52 illustrates Bot50 prices and parameters for each roll stack
  • Fig. 53 illustrates an embodiment of the processing flow for Bot51
  • Fig. 54 illustrates the distribution of stacks for a roll
  • Fig. 55 illustrates an embodiment of the operation of Bot5X engines
  • Fig. 56 an embodiment of the input and output messages and processing flow for Bot5X engines
  • Fig. 57 illustrates an embodiment of price filter inputs, intermediate calculations and outputs
  • Fig. 58 illustrates an embodiment of how the radius multiplier for Bot70 decreases over the live span of an order
  • Fig. 59 illustrates an embodiment of how a time interval for an order is determined by the time and number of orders remaining
  • Fig. 60 illustrates an exemplary processing flow for Bot70
  • Fig. 61 illustrates a secondary processing flow for Bot70
  • Fig. 62 illustrates an emobidment of how the radius multiplier for Bot70 decreases over the live span of an order
  • Fig. 63 illustrates how the time interval for an order is determined by the time and number of orders remaining
  • Fig. 64 illustrates an exemplary processing flow for Bot70
  • Fig. 65 illustrates a secondary processing flow for Bot70
  • Fig. 77 illustrates a secondary processing flow for Bot8X
  • Fig. 78 illustrates an embodiment of how Bot90 estimates volatility for a specified time interval ⁇
  • Fig. 79 illustrates the Calendar effects over the last five weeks of 2001
  • Fig. 80 illustrates the time of day, holiday and Asian daylight savings time effects
  • Fig. 81 illustrates an economic calendar effects
  • Fig. 82 illustrates an exemplary processing flow for Bot90
  • Fig. 83 illustrates an embodiment of BotBase
  • Fig. 84 illustrates an embodiment of a BotFilter
  • Fig. 85 illustrates an embodiment of a class hierarchy
  • Fig. 86 illustrates an embodiment with a primary and secondary instance of a Bot running on servers in physically different locations
  • Fig. 87 illustrates an embodiment for the initialization of a bot when a primary bot is not running
  • Fig. 88 illustrates an embodiment for the initialization and updating of state variables 1 -NY/1922896.1 Q for the secondary bot
  • Fig. 89 illustrates an embodiment for the initialization of the order book for a cold start of a primary instance of Bot41
  • Fig. 90 illustrates an embodiment for the initialization and updating of state variables for the secondary bot at different stages in the bot life cycle: initialization, maintenance and activation of the bot
  • Fig. 91 illustrates a Bot Overview in the present systems and methods
  • Fig. 92 illustrates an embodiment of price filter inputs, intermediate calculations and outputs
  • Fig. 93 illustrates an embodiment for the calculation of a radius
  • Fig. 95 illustrates a processing flow for a price screen
  • Fig. 96 illustrates an embodiment of the processing flow for a quote
  • Fig. 97 illustrates an embodiment of the processing flow to construct a price from the OCR
  • Fig. 98 illustrates an embodiment of the flow for a deal filter
  • Fig. 99 illustrates an embodiment of a priority match
  • Fig. 100 illustrates an embodiment of a shift match
  • Fig. 101 illustrates an embodiment of an unmatched deal
  • Fig. 102 illustrates an embodiment of a nearest match
  • Fig. 103 illustrates an embodiment of the flow for the gridViewer client
  • Fig. 104 illustrates an embodiment of the flow for the ManualTrader engine
  • Fig. 95 illustrates a processing flow for a price screen
  • Fig. 96 illustrates an embodiment of the processing flow for a quote
  • Fig. 97 illustrates an embodiment of the processing flow to construct a price from the OCR
  • Fig. 98 illustrates an embodiment of the flow for a
  • 105 illustrates a plot of a risk book
  • Fig. 106 illustrates a plot of a net risk
  • Figure 107 illustrates an embodiment of the main operating sections of a match engine
  • Figure 108 illustrates an embodiment of the match engine cluster topography.
  • Fig. 1 is a system diagram illustrating various aspects of a foreign currency exchange trading system 100.
  • System 100 includes a first stack applet client 102, and second stack applet client 104 shown as running on a desktop computer. While two clients 102 and 104 are shown for ease of discussion, it will be recognized that the present invention can typically be deployed with any number of customers or users using any number of clients running on desktop computers, laptops, handheld computers or any other appropriate computer devices.
  • client 102 and the computer it is running on are connected by a private network connector 112 to a Financial Information Exchange (FIX) client server 106, as well as FIX Servers 122 and applet servers 124.
  • FIX Financial Information Exchange
  • a single computer or server for example, 122 or 124 shown in Fig. 1, can be representative of any number of servers.
  • Client 104 and the computer it is running on are connected by a public network 114 to applet servers 124 and settlements web servers 126.
  • a single web server 126 is shown for purposes of simplicity of illustration, multiple servers can be employed.
  • Appropriate fire wall, encryption or other security measures also can be employed.
  • any suitable private, public, or dedicated network can be used (e.g., intranet, Internet, LAN, WAN, etc.)
  • Servers 122, 124, and 126 are connected to a trade management server (TMS) 132.
  • TMS trade management server
  • RVCM rendezvous certified messaging
  • TMS 132 serves as a front end for match engine 130 which additionally includes match engine servers 134, 136, and 138. Further details of order matching are provided below.
  • TMS 132 is connected to market maker computers 142, 144, and 146. Such computers can be desktop computers, laptop computers, or smaller handheld computers. Again, an RVCM communication protocol can be employed. TMS 132 can also be connected to a memory 152 to store settlement data and a memory 154 to store market trade data, both of which memories are shown as databases. It will, however, be recognized that other memory devices for storing such data may be utilized. TMS 132 can also be connected to a bank of RISC processors 158 to provide trade processing (such as rollover 1 -NY/1922896.1 ⁇ ⁇ 87
  • Fig. 2 shows further details of a preferred implementation of parts of the system 100 of Fig. 1.
  • a redundant system is envisioned (e.g., a system with components located in two locations, such as New Jersey and New York).
  • the components of Fig. 2 also can include firewalls 118, model engines 140, infrastructure service servers 150, and databases 160 which would include databases 152 and 154 as well as associated database processing components.
  • the model engines 140 enable and support the execution of mathematical strategies based upon one or more external data sources, such as trade data, government reports, interest rates, weather reports, and the like.
  • trading software can be downloaded remotely from applet servers 124 for use during a particular trading session. This approach gives a customer the flexibility to trade from anywhere by logging on with a user ID and a password to access the system. Thus, customers do not need to use a particular computer or be in a particular location to access the system. Further, a traveling customer need not call back to the office and have someone carry out voice instructions on a dedicated machine. Rather, a customer can access the applet client 124 through any suitable computer connected to an appropriate network (such as the Internet), sign in using suitable security measures, and then download software (e.g., JAVA applets) which then are stored on his computer.
  • an appropriate network such as the Internet
  • a user can access the system and enter trading orders using custom client software supported by a client server, such as server 106 of Fig. 1.
  • the downloaded client can be installed on a hard drive of a computer to be used for trading purposes.
  • a regular confirmation will be preferably made upon sign-in, confirming that the most current software build is being employed.
  • Automatic updating can be implemented where it is determined that the most current software is not in use. Safeguards preferably are employed to ensure that only licensed equipment is allowed to download the system software, so as to prevent unauthorized duplication and possible misuse thereof.
  • web pages or screen shots of displays such as displays 300-1500 depicted in Figs. 1-NY/19 22 896 1 12 22187
  • 3-15 can be used by clients to enter orders, check account status, and the like, as further explained below.
  • Fig. 3 shows an exemplary price monitor display 300 for use in connection with the present systems and methods.
  • the three major currency pairs Euro ( €) and U.S. dollar ($) (EURAJSD pair 310, U.S. dollar and Japanese yen ( ⁇ ) (USD/JPY) pair 320, and Euro and Japanese yen (EUR/JPY) pair 330
  • Each pair has its respective bid price (312, 322 , and 332), its respective ask or offer price (314, 324, and 334), and its respective contract closing date (316, 326 and 336).
  • Beneath bid and offer blocks 317 and 318, 327 and 328, and 337 and 338 the number of bidders and offerors at the current bid and offer prices are shown. For example, there are three bidders at the current bid price for EURAJSD and one offeror at the current price. The above information is familiar to users of the EBS interdealer platform.
  • display 300 includes blotter button 340, stack button 350, and ticket button 360 near the top of the display, as well as exit button 370.
  • Each currency pair has its own respective stack button (319, 329, and 339) located beneath the current bid and offer prices. The function of these buttons is explained below in connection with the discussion of Figs. 4-6.
  • Fig. 4 When a user wants to see trade blotter display 400 of Fig. 4, she selects that display by clicking on trade blotter button 340 in the price monitor display 300. In the trade blotter display 400, details for all deals are displayed. The user can scroll up or down or left or to view trade blotter details. To focus on only open deals, the user can click on an Open Deals button 402. To focus on closed deals, the user can click on a Close Deals button 404. To return to an all deals display from an open or close deals display, the user clicks on All Deals button 406.
  • deal details are arranged in columns 405-411 : trade date 405, state 406, symbol 407, side 408, original price (OrigPx) 409, average price (AvgPx) 410, and last price (LastPx) 411. Additional relevant information can be displayed by adding additional columns.
  • additional columns may include original quantity (OrigQty), last quantity (LastQty), filled, account number (Account), and type.
  • server 106 of Fig. 1 a user can customize a trade blotter display to suit his specific needs. It will be recognized that a Java applet approach can allow a system operator to readily update or upgrade the display to adapt it to other types of trades or to address l-NY/1922896.1 13 87
  • stack display 500 causes stack display 500 to be displayed.
  • stack data can be displayed for the EUR/USD pair as a default.
  • drop down menu 502 the user can select stack data for the USD/JPY, EUR/JPY, or other defined currency pairs.
  • the user can also click on the individual stack buttons 319, 329, or 339 to go directly to the stack data display for a desired currency pair.
  • a date block 504 displays the current day's date.
  • a block 506 shows the status of trading.
  • block 506 can also indicate a fixed exchange price for contracts closing that day. As seen in display 500, the active price is $1.13565 $/ €.
  • a time to settlement block 508 shows the hours and minutes to settlement and a time to close block 510 similarly shows the hours and minutes to close.
  • An account block can also be incorporated to show a default account name and can include a drop down menu to display other account names where multiple accounts are being traded.
  • Display 500 preferably includes stack data display blocks 520, 530, and 540 for contracts settling on three different days (in this example, July 8th, 9th, and 10th).
  • the middle block (530) is for the spot trading date
  • block 520 is for spot day - 1
  • 540 is for spot day +1.
  • block 523 shows quantity (QTY) in a column 522 and price (PX) 524 in a column 525.
  • block 520 shows offer data, in columns for price 526 and quantity 527.
  • each display block 520, 530, and 540 can have corresponding bid and offer sections that contain columns indicating quantity and price, as described in connection with block 520.
  • block 530 depicts 1 bid at 1.1356 ("56") and two columns of quantity and price, as well as 7 bids at 1.1357 with two columns of price and quantity.
  • Each order processed by the system 100 may be assigned a sequential number and placed in a stack of pending orders, based upon the time at which it is received and the 1 -NY/1922896.1 14 5 022187
  • a user can see the following information. First, one bid was placed for one contract at the current bid price. An additional bid was placed for five contracts at 1.1353. One bid was placed for two contracts at each of 1.1352, 1.1350, 1.1349, and 1.1348. One bid was placed for 4 contracts at 1.1348. Two bids were made for 3 contracts each at 1.1347, and one bid was made for two contracts at 1.1346.
  • Display block 520 includes similar offer stack data 524, and display blocks 530 and 540 have their own bid and offer stack data 532 and 534, and 542 and 544, respectively. While in the display 500 only ten orders are shown in each stack, it will be apparent that more or less orders can be displayed as desired.
  • the additional price and quantity data enables users to better gauge which bid or offer is appropriate for a particular trading goal. For example, and by way of comparison, a user seeking to buy or sell ten July 8 contracts, using a system that only indicates that there is 1 bid at 1.1355 and 7 offers at 1.1358, is at a disadvantage with respect to someone with the same trading goal presented with the stack data shown in display 500.
  • a user's own orders preferably are highlighted in the stack data, allowing the user to track and evaluate the competitiveness of his order, as well as to gauge the likelihood of it being filled.
  • the placing and tracking of these orders also increases the liquidity of the market provided by the system.
  • orders can be color coded based on price or quantity, to expedite information assimilation.
  • the system can be configured to automatically execute the trade.
  • executed contracts preferably are no longer displayed on the stack. Instead, executed contracts preferably are shown in a separate open transactions window (e.g., a trade blotter window as shown in Fig. 4).
  • roll blocks 550, 560, and 570 are depicted in Fig. 5.
  • Block 550 shows 10 bids at .00005 and 10 offers at .00005.
  • the quantity (551) of each bid is shown in column 552.
  • the price (553) of each bid is listed in a column 554.
  • Columns 555 and 556 illustrate the price and quantity for roll offers.
  • roll block 550 pertains only to rolling spot -1 to spot (i.e., 1 -NY/1922896.1 15 rolling July 8 transactions into July 9 transactions).
  • a user wishing to "purchase the roll” from July 8 to July 9 can place her bid price for a particular quantity.
  • the roll market compares the July 8 outright market to the July 9 outright market. If a user is long for the July 8 EUR/USD currency non-deliverable forward (“NDF"), and wishes to extend the position to the July 9 NDF, he can effect this type of transaction by "buying the roll.”
  • the current offer in the July 8/July9 roll is .00005. So if a user is long 10 EUR/USD NDFs at 1.1355, and he buys the roll at .00005, his new position would have an effective rate of 1.13555.
  • the roll trade requires that some amount of July 8th NDFs be sold and the same amount of July 9th NDFs be purchased.
  • a user can roll it from its current contract to a different contract (i.e., roll from current maturity to next maturity, or two days maturity, etc.). For example, if the user were to buy Yen on Monday, the Yen would go into the user's account on Wednesday as Yen trades typically settle in two days. If the user did not want to take possession of the Yen, he could roll the trade to the following day; namely, he could sell it back and then buy it back for value on Thursday without taking possession of the Yen. The trade also doesn't affect the user's account because the trades are net-settled.
  • the rolling a trade may prevent the trade from ever maturing.
  • the cost of accomplishing that transaction is the difference in the cost of the commodity today minus the cost of it tomorrow.
  • the cost to roll it would be a penny (in this example, the user would be charged a penny); if it depreciates one penny in value, the user's account would get credited a penny upon execution of a roll.
  • a roll transaction allows a user to roll a trade from one day to the next without having to book a buy and a sell. This capability creates a roll market.
  • a roll market allows for a number of different types of trades.
  • these can include: buy or sell on day 1, buy or sell on day 2, buy or sell on day 3, buy or sell a roll trade between value days 1 and 2, buy or sell a roll trade between value days 2 and 3, buy or sell a roll trade between days 1 and 3, and buy or sell a roll to spot cash.
  • each stack is selling a different commodity.
  • stack 1 is selling a blue commodity
  • stack 2 is selling a red commodity
  • stack 3 is selling a green commodity.
  • the user buys a blue commodity (which can be shown in a left hand stack on a display screen).
  • the user decides he wants to own the red commodity; so he enters into a roll trade where he buys a roll. (Effectively, what gets booked on exchange is: sell a blue commodity and buy a red commodity).
  • the user decides he doesn't want the red commodity, but instead wants the green commodity (which can be shown in a right hand stack on a display screen), he enters into another roll trade selling the red commodity and buying the green.
  • the user can also sell a roll trade. If he doesn't want the green commodity anymore, he can sell his position in the green and buy a position in red.
  • the cost of the roll trade is the difference in price between the green and red commodities.
  • the user can replace the green with the red without having to sell green and buy red.
  • roll data and stack displays can be displayed to a user simultaneously.
  • a roll trade is arbitrage free. If the difference between two stacks is not the price of the roll trade, there would be an arbitrage opportunity.
  • the forward value of a currency is relative to the interest rate in that currency.
  • the spot rate of the currency e.g., Yen
  • the interest rate of that currency the user could estimate what the one day and three day trade would be.
  • the spot market for Yen is two days forward
  • three days forward would be the spot price of Yen plus one day's interest on Yen.
  • interest rate parity provides that if the user were to buy Yen today and invest it in Tokyo, at the end of the year the user would end up with the same amount as if he invested in dollars.
  • interest rates are high in Tokyo and low in the US, the user would get fewer dollars back for Yen a year from now. Because the user made more on the interest, he would lose it in the exchange rate.
  • the difference in the one, two, and three day stacks is the interest rates in those currencies.
  • NDF product only has value on the exchange on which it was traded. Thus, it is 1-NY/192 28 96.1 ' ⁇ J T/US2005/022187
  • the exchange on which the user purchased the product is open when the user wants to trade the NDF. Because the stacks are tied to the cash market - a 24 hour market, and it is arbitrage free exchange, it is important that the market be open when the cash market is open.
  • spot +1 roll stack i.e., July 10 stack
  • This block also illustrates 10 bids at .00005 and 10 offers at .00005. Further shown are quantity and price for the bids (571 and 572 respectively) as well as price and quantity for offers (575 and 576 respectively).
  • spot roll stack 560 i.e., July 9 stack. As described above, this stack allows users to roll to cash in an arbitrage free environment.
  • any number of computer engines can be implemented to perform various tasks related to the systems and methods described above.
  • a matching engine can be implemented to maintain an order book and to match orders between buyers and sellers (e.g., a matching engines can determine when a client order crosses the market, and can automatically execute the order).
  • Various stack displays of the above systems and methods can represent market making offers to buy/sell. In such instances, when bids/offers cross into a different stack, the trade will execute. When there are orders for the same price, the buyer and seller are notified and the trade is moved into the executed stack.
  • order entries in the stacks may be prioritized by time/price matching (e.g., if there are two orders in the stack for 45, the earliest in time will execute first).
  • a priming engine can be used to prime stacks with a broker's orders.
  • other engines can maintain price spreads, maintain stack depths, search for cross currency arbitrage opportunities, adjust the liquidity of the broker's market, isolate orders from certain users, manage orders, and manage roll markets.
  • This exemplary order ticket display preferably includes a user account block 602 with a drop down menu for additional user accounts, a date block 604 with a drop down menu enabling a user to select a contract date by checking on the desired contract date, and a currency pair block 606 with a drop down menu enabling a user to readily select the desired currency pair.
  • block 608 allows the user to select the desired side of the transaction.
  • Price block 610 and quantity block 612 allow the user to establish a price and quantity.
  • An update price (UpdatePx) block 614 can be clicked to update the price for an existing order using the price block 610 to reflect a changed judgment on the correct price, to reflect a change in market conditions, or the like.
  • Ready block 616 allows a user to confirm that the order is correct and ready to submit and send block 618 allows a ready order to be submitted.
  • Close block 620 allows a user to close the active order ticket display window.
  • Blotter block 622 allows the user to display the blotter screen, and Cancel block 624 allows the user to cancel any activity associated with the current ticket window.
  • a ticket display such as that depicted in Fig. preferably 6 is the primary device for entering orders.
  • the account, date, currency pair, price, quantity, and the intention to bid or offer can be controlled through the blocks displayed.
  • Figs. 3-6 and their corresponding descriptions collectively illustrate tools utilized by users to learn about market conditions, open and close orders, and roll in and out of positions.
  • Figs. 7-15 illustrate preferred account management and settlement tools related to the present systems and methods.
  • a user can readily navigate through one or more screens to learn pertinent account details and advantageously manage one or more accounts.
  • Exemplary display 700 provides account summary data arranged in columns by account number 702, account name 704, realized profit and loss (Realized P & L) 706 and unrealized profit and loss (Unrealized P & L) 708.
  • Navigation to further account details can be readily accomplished utilizing menu select buttons, such as Account 710, Trade History 712, Fixing 714, Customer 716, Tools 718, Summary 720 or Info 722 (discussed below in connection with Figs. 8-15).
  • a particular account number such as account number 724, LBOOLOOl, or account number 726, LEH_ARB_SSRUSD/JPY, a user can navigate to a display showing further account details.
  • FIG. 8 A user who wants to see further account data and clicks account menu select button 710. This selection results in account display 800 of Fig. 8 being displayed.
  • Display 800 shows account details for the first listed account number 724, LBOOLOOl. Paging down allows details for the remaining accounts to be displayed in a similar manner.
  • account details are displayed in columns as follows: security 802, 1-NY/19 2 2896.1 19 position 804, average price 806, current market price 808, realized profit 810 and unrealized profit 812. It will be recognized that other formats with additional or other information would be suitable, depending upon the user.
  • Query Trade History display 900 of Fig. 9 would be displayed.
  • a user can drill down to the specific details of the history of a specific trade by entering (or selecting) a specific known trade number.
  • Account currency pair information can be selected using a drop down menu 904. Date ranges can be specified using start and end dates 906 and 908, or a period can be selected from a period drop down menu 910.
  • Security pair types can be selected by checking one of the pair boxes 912, and the output format can be selected using a format drop down menu 914. The query is submitted by clicking a submit button 916.
  • Fixing History display 1000 of Fig. 10 would be displayed.
  • date range and period searches can be conducted by clicking an appropriate bullet and using start and end dates 1006 and 1008, or a period drop down menu 1010.
  • a security type can be selected using a security selection menu 1012, and the query can be selected by clicking submit button 1016.
  • customer information display 1100 of Fig. 11 would be displayed.
  • customer contact details such as mailing address, phone, and email address are shown. Settlement instructions for a number of different accounts may be displayed.
  • Tools button 718 of display 700 of Fig. 7 account, preference, and user definable tools will be accessible from a web page displayed in response to clicking this button.
  • summary button 720 If summary button 720 is clicked, then a summary list of accounts display 1200 shown in Fig. 12 is displayed. Accounts are listed on display 1200 in account number 1202 and account name 1204 columns.
  • Fig. 13 is an exemplary list of account details display 1300 reached by clicking on specific account name 726 of display 700 of Fig. 7.
  • Fig. 14 shows a settling position breakdown display 1400 providing settling position 1-NY/19 22 896.1 20 details for the account 726 whose account details are shown in Fig. 13.
  • Fig. 15 shows a trade detail display 1500 for a specific trade 1502, trade number 22810386.
  • Figs. 7 addition functionality can be implemented in connection with Figs. 7, such as providing users with an independent settlement mechanism to settle orders placed in connection with the embodiments described above.
  • NDFs that settle on a particular date can be settled through such an independent settlement mechanism.
  • Independent settlement mechanisms can potentially reduce millions of dollars from traditional settlement process costs. This cost savings can provide a liquidity edge due to lower marginal transaction costs.
  • Fig. 16 is a composite block/flow diagram illustrating preferred configuration and operation of an embodiment of the present invention. Shown in Fig. 16 are a client 1600, server 1610, client account 1620, exchange account 1630, trading servers 1640, and market 1650. A client may submit an order to the server 1610 through connection 1602. This preferably is a two way connection, allowing the server to transmit messages to the client. Server 1610 can represent any trading market can be a single server, or a plurality of servers, including the matching engine described above.
  • Server 1610 is tethered to the cash market 1642 through the trading servers 1640.
  • These can be bots, and their functionality is described in Appendix A.
  • the bots listen to all orders, and when they recognize that an order can be filled in the cash market, the bot is operable to fill that order in the cash market.
  • client 1600 submits an order for 5 Euros to server 1610.
  • the order gets filled via by the exchange account 1630 and the client is notified via connection 1602.
  • the client account 1620 is updated via connection 1614 and the exchange account gets debited through connection 1616.
  • client account 1620 and exchange account 1630 can be connected via connection 1622 to facilitate order completion.
  • the client account will then be + 5 Euros and the exchange account will be - 5 Euros.
  • trading servers 1640 "see” that an order has been made by the client and filled by the exchange server for 5 Euros, and can then go to the cash market and obtain 5 Euros.
  • An order is placed in the cash market for 5 Euros and the order is filled via
  • connection 1642 1-NY/192 2 896.1 21 connection 1642.
  • the trading server sends an order to server 1610 via connection 1612. This order gets filled and the exchange account is updated + 5 Euros.
  • server 1610 can implement the order book, stacks, rolling stacks, settlement methods, and account information described above.
  • server 1610 can implement the order book, stacks, rolling stacks, settlement methods, and account information described above.
  • the components and functionality of Fig. 16 can be implemented in accordance with the description provided in connection with Fig. 1.
  • Fig. 17 is a flow diagram illustrating the operation of an embodiment of the present systems and methods.
  • a user opens a trade window.
  • the trade window allows a user to view current trading information, and also allows a user to access various displays and foreign exchange functionality as described above.
  • a window can be a price monitor window as described in connection with Fig. 3.
  • a user may elect to open windows in any particular order, flow is described in an arbitrary order below (e.g., flow may proceed to step 1704, 1706, or 1708, ' as the user desires). Additionally, links may be provided to enable a user to move from one window to any other window.
  • direct links may be provided in each window 1702, 1704, 1706, and 1708 enabling a user to switch to any other window.
  • a user can omit any steps, revisit any windows in any order, or return to the trade window at any time.
  • one display window can be configured to display the information contained in windows 1702, 1704, 1706, and 1708.
  • the information contained in windows 1702, 1704, 1706, and 1708 may be divided between any number of display windows.
  • the present systems and methods are capable of presenting the information in numerous ways.
  • the user opens a stack window.
  • a window can contain information as described above in connection with Fig. 5.
  • the stack information can contain a bid section and an offer section, with each section containing two columns of information related to a particular settlement date.
  • the two columns contain sorted price and quantity information.
  • Such a window can contain stack data for any number of settlement days. This information allows a user to determine whether to place an order, and if so, at what price to place the order.
  • the stack data can contain data for the spot settlement day, or may 1 -NY/1922896.1 22 contain information for the spot settlement day -1, or for the spot settlement day +1, etc.
  • the stack window can contain data for two days (e.g., spot and spot -1, spot and spot +1, or spot -1 and spot +1).
  • the stack window can be configured to display data for any number of days (e.g., 3 days (spot, spot -1, and spot +1)).
  • the stack window can be configured to display additional information as discussed above, and each window may be configured to display links to other windows.
  • prices and quantities for each displayed settlement date provide relevant trading information to users, enabling them to determine whether to place orders for a particular settlement date, and where their orders would fall in the displayed stack. With this information users can better gauge which order is appropriate for a particular trading goal.
  • stack window 1704 can display and highlight the user's current position in the stack.
  • the user opens a ticket window. Details of a preferred ticket window are discussed in connection with Fig. 6.
  • the ticket window is the mechanism used to place a particular order. Such windows can provide a user with the ability to select a currency pair, settlement date, price, quantity, and type of order to be placed. After selecting relevant criteria, the user places an order, which is submitted to the system.
  • the order window can also provide a mechanism to cancel an order. As discussed above, the window may also provide links to other windows.
  • step 1708 the user opens a trade blotter window. Details of a preferred trade blotter window are discussed above in connection with Fig. 4. As discussed above, the trade blotter window allows a user to view all orders, including open, closed, and cancelled orders. Certain relevant information about the orders is displayed in columns in the display window. If a user has no open trades, the trade blotter will have no trades to display. As discussed in connection with step 1716, where a user has previously placed an order, including on previous days, the trade blotter window 1708 can display the user's current orders.
  • steps 1712, 1714, and 1716 may be performed.
  • a user may elect to open windows in any particular order, flow is described in an arbitrary order below (i.e., flow may proceed to step 1712, 1714, or 1716, as the user desires).
  • Links may be provided to 1 -NY/1922896.1 23 enable a user to move from one window to any other window. As will be recognized, a user can omit any steps, revisit any windows in any order, or return to the trade window at any time.
  • a user opens a stack window. Details of a preferred stack window are discussed above. Where a user has an open order, the relevant information is displayed in the stack. In an embodiment, the user's order is highlighted on the screen. As will be recognized, the stack can sort data based on price and quantity; accordingly, the user's order will be displayed in the appropriate location in the stack. As orders are filled, placed, or cancelled, the user's new position will be displayed automatically or via a manual refresh.
  • step 1714 a user opens a trade window to place an order as discussed above.
  • a user opens a trade blotter window to view his current orders.
  • the trade blotter window is configured to display all orders for a particular user.
  • a user may continue to view that stack, place orders, or review the trade blotter as desired.
  • orders may settle on a particular day.
  • she may purchase a roll as described in detail above and below in connection with Fig. 20.
  • Fig. 18 is block diagram depicting displays corresponding to steps of Fig. 17.
  • a user can open a trade window 1802 (corresponding to step 1702).
  • the trade window displays relevant trading information to the user for the three major currency pairs, and also provides links to the various display windows described in connection with Fig. 17.
  • the user selects the stack display 1804 (corresponding to step 1704).
  • display 1804 illustrates the current bid and offer stacks, with columns indicating the prices and quantities for all bids and offers. Based on this information, the user elects to place an order.
  • the user may open a ticket window 1806 (corresponding to step 1706). As shown, the user elects to place an offer at a price of 1.1236 for a quantity of 10,000. When a user clicks send, the order is sent to the system.
  • Fig. 19 is a block diagram depicting displays corresponding to other steps of Fig. 17.
  • a user can open a trade window 1902 (corresponding to step 1702).
  • the trade window displays relevant trading information for 5 different currency pairs.
  • the trade window can be configured to display any number of currency pairs.
  • Trade window 1902 also provides links to the various display windows described in connection with Fig. 17.
  • the user selects the stack display 1904 (corresponding to step 1704).
  • the user waits approximately 10 minutes, and a reviews a subsequent stack window 1906.
  • this window may automatically update or be manually refreshed. As shown, the current prices have changed between display 1904 and 1906.
  • Displays 1908-1914 illustrate an order flow where a user cancels a first offer and submits a second offer that is accepted (corresponding to steps 1706 and 1710).
  • a user modifies the order window, and in connection with display 1910 sends an order that is acknowledged.
  • the user cancels the order, and in connection with display 1914 the user places a subsequent order.
  • the user reviews the trade blotter window. As shown, the user's previous cancelled order and the accepted order are displayed.
  • Fig. 20 is a flow diagram illustrating preferred operation of a roll trade. Such trades were previously unavailable in the foreign exchange market. As discussed above, by providing a rolling mechanism, new roll markets have been created.
  • a user places an order. Placing an order is described in detail above.
  • Each contract has a settlement date (also called a spot date, or spot settlement date).
  • a settlement date also called a spot date, or spot settlement date.
  • orders generally settle within two days of the date on which the order is placed. For example, if a user orders ⁇ 10,000 on a Monday, the Yen will normally be delivered to the user's account on Wednesday.
  • a user may roll any open contracts into another settlement day.
  • a user has orders that will settle 1 day before the current spot date (spot date -1). For example, if a user places an order on Monday, the spot date would be Wednesday, and the spot date -1 would be Tuesday. Accordingly, if a user had any open contracts that would settle on Tuesday, he could roll those contracts into another settlement date.
  • step 2010 If a user wishes to settle, flow continues to step 2010, and the orders would settle on their settlement date. If a user does not wish to settle, flow proceeds to step 2012. If the user wishes to roll, flow proceeds to step 2018. If the user does not wish to roll, flow continues to step 2004.
  • a user can configure the system to automatically settle or to automatically roll 1 -NY/1922896.1 25 22187
  • open trades In an embodiment, open orders automatically settle on the settlement date. In an embodiment, open orders automatically roll to the next settlement date.
  • roll transactions allow users to roll trades from one day to the next without having to book a buy and a sell, thereby creating a roll market (providing a roll for users roll contracts settling on spot date -1 to the spot date).
  • bids and offers for spot date — 1 are displayed in the stack viewer, and users can place orders for contracts settling in one day, rather than contracts normally settling in two days. Further, users can place orders for rolling contracts from one settlement date to another date.
  • a roll market allows for a number of different types of trades.
  • these can include: buy or sell on day 1 (spot date - 1), buy or sell on day 2 (spot date), buy or sell on day 3 (spot date + 1), buy or sell a roll trade between value days 1 and 2, buy or sell a roll trade between value days 2 and 3, buy or sell a roll trade between days 1 and 3, and buy or sell a roll to spot cash.
  • a user may purchase a roll from spot - 1 to spot + 1.
  • step 2006 a user has orders that will settle on the spot date.
  • the user may elect to do nothing for one day, whereby flow would continue to step 2004.
  • a user may wish to settle on the settlement date, and flow would continue to step 2010.
  • a user also may elect to purchase a roll to spot + 1 (step 2014). If so, flow continues to step 2018, whereby a roll from spot to spot + 1 has been purchased. Additionally, as described above, a user may elect to roll open contracts to cash.
  • spot +2 is not shown in the stack view of Fig. 5, it may be configured to display any number of days.
  • FIGURE 21 illustrates price filter inputs, intermediate calculations and outputs.
  • FIGURE 22 illustrates an embodiment for the calculation of a radius.
  • R 0 parm.RadiusMaxSpread * parm. SpreadTol * C;
  • FV 0 PRI CE-BLANK;
  • B 0 PRICE_BLANK;
  • a 0 PRICEJBLANK;
  • BotlOX provides liquidity to the LEH market by partially filling orders that constrain the DAR market.
  • the filled orders are contingent of filling an equivalent (or worse) order in the DAR market.
  • FIGURE 23 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
  • FIGURE 24 illustrates a bot responsible for executing partial arbitrage orders that keep the LEH non-deliverable markets in line with the DAR deliverable market.
  • FIGURE 25 illustrates a process flow for the bot illustrated in FIGURE 24.
  • DarBidArb DarBidPrice ⁇ LehAskPrice + AskArbDelta
  • DarAskArb DarAskPrice ⁇ LehBidPrice - BidArbDelta ifUNoLehAsk && DarBidArb) ExecuteArb("DARSeIl”) ifUNoLehBid && DarAskArb) ExecuteArb("DARBuy”) if(IDarBidArb
  • BuyRollImprove, arbRollSize // execute remaining arb If(arbSize>0) ⁇ submitOrder ('DAR', "2Day' , "SELL', DarBidPrice - parameter.SellDarlmprove, arbSize) submitOrder (""LEH', "2Day', 'BUY', LehAskPrice + parameter.BuyLehlmprove, arbSize) ⁇
  • BotlOX subscribe to the following messages
  • BotlOX publishes the following messages:
  • BotlOO BotlOO provides liquidity to LEH orders from the "INCL" price feed.
  • the INCL feed includes all customer orders including on a specific list.
  • Botl 01 BotlOl provides liquidity to LEH orders from the "EXCL" price feed.
  • the EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
  • FIGURE 26 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
  • FIGURE 27 illustrates a bot responsible for executing partial arbitrage orders that keep the LEH non-deliverable markets in line with the DAR deliverable market.
  • FIGURE 28 illusrates a BotlOX responsible for executing cash to roll arbitrage orders.
  • such orders keep both the LEH deliverable and non-deliverablemarkets in line with the DAR deliverable market.
  • a cash to roll arbitrage order can be accompanied by a regular arbitrage order.
  • FIGURE 29 illustrates a process flow for BotlOX.
  • ProcessNewDARPriceQ // Process New Bid; If its a futures price, then use MinArbSize and // remove our own orders from price,- eventually, this should include // orders from other bots UpdateMarketDataCache(DarBidPrice, DarBidSize, MinArbSize, PriceMarket) ;
  • TargetOrderSize ! DarLimitAsk.Size) cancelReplaceOrder
  • BotlOX subscribe to the following messages
  • BotlOX publishes the following messages:
  • BotlOO Botl 00 provides liquidity to LEH orders from the 'TNCL" price feed.
  • the INCL feed includes all customer orders including on a specific list.
  • Botl 01 Botl 01 provides liquidity to LEH orders from the "EXCL" price feed.
  • the EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
  • BotlOX engine executes simple arbitrage opportunities that exist between an underlying and future currency pair.
  • B 3 B f x exp(- ⁇ r x d / 365)
  • a a A f x exp(- ⁇ r x d / 365)
  • FV a FV f x exp(- ⁇ r x d / 365)
  • FIGURE 30 illustrates a type 1 arbitrage.
  • a type 1 arbitrage is defined as when the synthetic futures price exceeds the spot price by the arbitrage threshold ArblMinDelta.
  • FIGURE 31 illustrates a type 2 arbitrage.
  • a type type 2 arbitrage is defined as when the synthetic futures price is less than the spot price by the arbitrage threshold Arb2MinDelta.
  • the spot contract for USD/JPY has a contract size of 1 million and the futures contract for JPY/USD has a contract size of 12.5 million.
  • a single spot contract at 116.14 ⁇ per US$ is equivalent in size to 9.29 futures contracts. Since it is not possible to trade a fraction contract size, a residual balance will remain.
  • FutBidPx synthetic best bid
  • FutBidSz synthetic size at the best bid
  • SpotBidPx best bid
  • SpotBidSz size at the best bid
  • FutAskPx RawToSyntheticPrice(raw.AskPrice, futlnfo);
  • FutBidPx RawToSyntheticPrice(raw.BidPrice, futlnfo);
  • FutAskSz RawToSyntheticSize(raw.AskSize, FutAskPx, futlnfo);
  • FutBidSz RawToSyntheticSize(raw.BidSize, FutBidPx, futlnfo);
  • arbSize Math.Min(FutBidSz, SpotAskSz, MaxArbSize) ;
  • arbSize Math.Floor(arbSize/1000000)*1000000;
  • Botl20 uses an algorithm to sell a fixed inventory over a time period at a uniform rate.
  • the algorithm optimizes the price under the following assumptions:
  • the only type of crossing orders are market orders with no price restriction. • We only send out and update orders at regular time intervals separated by ⁇ seconds. • The probability that a crossing order occurs in a time interval ⁇ is ⁇ t . • The size of a crossing order has an exponential distribution with mean ⁇ t . • The probability that our limit order is filled or partially filled depends on ⁇ t , ⁇ t and the total size of orders in front of our limit order ⁇ t. • We only know about market orders that trade against our orders. • We set a limit on the maximum order size at any time.
  • Botl20 is characterized by "trading sessions" where a trading session is started when trading is turned off and ended when inventory is used up or trading is turned off. Once a sessions is ended, it cannot be restarted.
  • FIGURE 32 illustrates the processing Flow for Botl20.
  • FIGURE 33 illstrates the notional stacks of Bot20.
  • Bot20 maintains four notional stacks, each with a target distribution.
  • FIGURE 34 illustrates an embodiment for protecting against pick-offs on bids in the stack
  • FIGURE 35 illustrates an embodiment for protecting against pick-offs on asks in the stack.
  • RollMid Midquote for the rolls from LehDate to DarDate.
  • FIGURE 36 illustrates four notional stacks for Bot2X.
  • each stack can have a target distribution.
  • FIGURE 37 illustrates an embodiment for protecting against pick-offs on bids in the stack.
  • FIGURE 38 illustrates and emobidment for protecting against pick-offs on asks in the stack.
  • Order Gating is used for markets in which we can only maintain a limited number of actual orders in the stack.
  • the Bot maintains a virtual stack
  • parameter refresh messages "LEH . MERLIN . CTRL . BOT2 O . ⁇ coiumn> . OUT"
  • Bot22 Engine Background Bot22 maintains orders at the top of the market according to a fair-value and threshold.
  • FIGURE 39 illustrates the operation of one embodiment of Bot22. l-NY/1922975.1 36
  • Bot22 is an electronic market making engine for the DAR market. It maintains one or more bids and offers on each side of the market. If the market price moves away from one side of Bot22 orders, then Bot22 cancels the order furthest from the market and submits a new order close to the market.
  • the threshold for Bot22 can be taken from Bot20, or can be set independently.
  • FIGURE 40 illustrates thresholds and parameters as described in connection with Bot22.
  • Order book cache Bids active bids sorted from best price to worst
  • Asks active asks sorted from best price to worst
  • BidThresh[] vector of bid price thresholds
  • AskThresh[] vector of ask price thresholds
  • BidMinGap minimum gap between best market bid and the best Bot22 bid
  • BidMaxGap maximum gap between best market bid and the worst Bot22 bid
  • AskMinGap minimum gap between best market ask and the best Bot22 ask
  • AskMaxGap maximum gap between best market ask and the worst Bot22 ask
  • FIGURE 41 illustrates the flow of an embodiment of Bot22.
  • CheckNewBidO check to see if a new bid should be submitted
  • CheckNewAsk() check to see if a new ask should be submitted
  • CheckForTradingHaltO update information used to impose a trading halt
  • GeneratePriceO generate the price of a new order
  • GenerateSize() generate the size of a new order
  • SampleDiscreteO sample from a discrete probability distribution
  • Bot22 publishes the following messages:
  • the Bot3X engine executes arbitrage opportunities that exist between different markets.
  • the initial engine works with two markets: a primary market (DAR) and a hedging market (Stack).
  • DAR primary market
  • Stack hedging market
  • FIGURE 42 illustrates a type 1 arbitrage.
  • FIGURE 43 illustrates a type 2 arbitrage.
  • FIGURE 44 illustrates an embodiment of the processing flow for Bot3X.
  • Bot3X looks for an arbitrage opportunity.
  • Arbitrage processing flow 1) Update cache with new market data and execution reports 2) If an order is still open, then quit. 3) If the current time minus the time of the last order is less than minWaitTime, then quit. 4) If an arbitrage opportunity is available, then a) send an order to DAR b) send an order to LEH The size of each order is the minimum of the top of book for DAR and for the Stack.
  • Bot3X subscribes to the following messages
  • Bot3X publishes the following messages:
  • Bot30 Bot30 arbitrages DAR against LEH based on the "INCL" price feed from LEH.
  • the INCL feed includes all customer orders including on a specific list.
  • Bot32 provides liquidity to the LEH market by partially filling orders that constrain the DAR market.
  • the filled orders are contingent of filling an equivalent (or worse) order in the DAR market.
  • FIGURE 45 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
  • FIGURE 46 illustrates a process flow for the bot illustrated in Figure 45.
  • Bot32/33 subscribe to the following messages
  • Bot32/33 publishes the following messages:
  • Bot32 Bot32 provides liquidity to LEH orders from the "INCL" price feed.
  • the INCL feed includes all customer orders including on a specific list.
  • Bot33 Bot33 provides liquidity to LEH orders from the "EXCL" price feed.
  • the EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
  • FIGURE 47 illustrates an embodiment for the flow of Bot40.
  • the Bot40 engine serves two purposes:
  • the engine inputs market data from the bubble filter, controls from the game pad, and parameter changes from other engines (e.g., grid viewer/editor).
  • the engine outputs parameter change messages to StackBot, Bubble and ArbBot and trades to the Merlin OMS and the Stack.
  • Button 2 Engine Toggle The engine toggle cycles through the different types of trading engines: Bubble, StackBot, ArbBot and ManualTrader. The selection of the engine toggle determines which parameters the game pad is updating.
  • Button 3 On-Off Switch For the trading Bots, the on-off switch turns on and off trading. For the price filters, the on- off switch turns off arbitrage filter. The specific behavior of the on-off switch depends on the engine toggle setting: see the parameter spreadsheet for details.
  • Button 0 Auxiliary Switch
  • the auxiliary switch is engine dependent. For Bubble, StackBot and ManualTrader, the switch selects the set of parameters are being set through the throttles. For ArbBot, the switch turns on and off trading to DAR.
  • buttons can support manual trading actions. These buttons can be solely dedicated to trading and can operate regardless of the engine toggle setting.
  • the trading buttons only control manual trading.
  • Cancel buttons apply to the current engine selected by the engine toggle.
  • the bid/ask cancel button is pressed, an order is cancelled out of the top of the bid and ask stack respectively.
  • the bid/offer buttons and the buy/sell buttons apply on to manual trading regardless of the setting of the engine toggle. These buttons can be de-activated by the Trading on/off switch.
  • the bid/offer buttons place limit orders and the buy/sell buttons place "Immediate or Cancel" orders.
  • the price and size of the orders is determined by the BOT40 (trading) parameters.
  • the throttles control the settings for the key parameters.
  • the left and right throttle have a continuous action outputting values between -1 and 1 along two dimensions.
  • the auxiliary throttle is an 8-way discrete toggle.
  • the behavior of the throttles are engine dependent. In general, the right throttle controls the price/radius, the left throttle controls the size and the auxiliary throttle controls a secondary parameter.
  • Gamepad Input Bot40 listens to low-level game pad event messages.
  • parameter refresh messages "LEH . MERLIN . CTRL . BOT4 O . ⁇ column> . our »
  • Classes Bot40 has two types parameters:
  • Bot40 internal parameters switches for the engine, currency and parameter set.
  • Manual trading parameters used to determine the price and size at which trades are submitted.
  • bidPrice/askPrice/buyPrice/sellPrice is not NULL, then that price is used. Otherwise, the "auto-price" is used. 2.
  • the auto-price is determined from the cached fair value and radius a.
  • bidAutoPrice fairValue - bidRadiusMult*radius b.
  • askAutoPrice fairValue + askRadiusMult*radius c.
  • buyAutoPrice fairValue + bidRadiusMult*radius d.
  • askAutoPrice fairValue - askRadiusMult*radius 3.
  • the bidPrice/askPrice/buyPrice/sellPrice are set to NULL each time the engine toggle is changed to "BOT5X" or the currency toggle is changed. 4.
  • the bidPrice/askPrice are set to NULL if the price throttle button is pressed and the parameter model is "Bid/Ask”. 5.
  • the buyPrice/sellPrice are set to NULL if the price throttle button is pressed and the parameter model is "Buy/Sell”. 6.
  • the bidPrice/askPrice is updated when the price throttle is activated and the parameter model is "Bid/Ask”. If the price is NULL, then it is initialized to the auto-price. 7.
  • the buyPrice/sellPrice is updated when the price throttle is activated and the parameter model is "Buy/Sell”. If the price is NULL, then it is initialized to the auto- price.
  • FIGURE 48 illustrates a network diagram for Bot41.
  • Bot41 can act as a gatekeeper between the other bots and orders going to and from the markets.
  • the Bot41 engine is a centralized order management system for all Bots.
  • a centralized Bot OMS offers several benefits:
  • Bot41 can obscure any information specific to a single bot. 3. Abstracts the order away from the specifics of the market; this way, when we hook up new markets, we don't need to change the individual bots. 4. Maintains a central view of our position. 5. Can prevent Bots from trading with each other by rejecting orders that cross other Bot orders.
  • Cancel Replace order from Bots 1 Validate order: is order from DAR and in stack a) if invalid, reject order b) update price and size 2) If order is derive, a) change status to CancelReplaceP ending b) Convert the order to a new order message to send to the market 3) Else if order is Pending or CancelReplaceP ending, a) change status to CancelReplaceOnAck 4) Else if order is CancelReplaceOnAck, do nothing , 5) Else issue exception
  • Settlement date messages 1) If the settlement date has changed a) update the settlement dates b) send control message to all bots and currency pairs giving new FutSettDate's
  • Bot41 should send a message to all bots.
  • TimeOutTimer A timer should be set to perform the following actions at an interval specified by the parameter TimeOutTimer:
  • the Bot41 parameters can be changed through control message sent to Bot41.
  • Bot41 Warning and Error Messages When Bot41 issues warning or critical errors, it should publish associated info ⁇ nation to help diagnose the error. For example, if Bot41 can't find an order with the inbound client order ID, it should issue the following warning:
  • Bot41 can't find an order with the inbound match engine order ID, it should issue the following critical error message:
  • Bug Pending orders moved to reject pile are lost Description: Orders that don't receive acks in a timely manner are moved to the reject pile and then are effectively lost. Severity/Priority: This can leave orders hanging and allow the bots to trade against each other. Solution: Check the reject pile when acks, fills and cancels come in. Cancel orders that have receive an ack after having been moved to the reject pile. Time Estimate: Vz day
  • Priority Listen directly to orders from ME (not OMS) Priority: By listening to the ME, we can receive information quicker. The disadvantage is that the orders are not serialized, so we need to put in logic in Bot41 to handle this. Solution: Create a local cache for fills that arrive before acks. Process the orders in the cache when the ack arrives Time Estimate: 1+ day
  • FIGURE 49 illustrates a network diagram for Bot41.
  • Bot41 can act as a gatekeeper between the bots and orders going to and from the markets.
  • the Bot41 engine is a centralized order management system for all Bots.
  • a centralized Bot OMS offers several benefits:
  • Bot41 can obscure any information specific to a single bot. 3. Abstracts the order away from the specifics of the market; this way, when we hook up new markets, we don't need to change the individual bots. 4. Maintains a central view of our position. 5. Can prevent Bots from trading with each other by rejecting orders that cross other Bot orders.
  • Settlement date messages 2) If the settlement date has changed a) update the settlement dates b) send control message to all bots and currency pairs giving new FutSettDate's
  • Bot41 should send a message to all bots.
  • TimeOutTimer A timer should be set to perform the following actions at an interval specified by the parameter TimeOutTimer:
  • Bot41 parameters can be changed through control message sent to Bot41.
  • Bot42 engine changes bot parameters according to a timer and/or to market events. Timers can be created and destroyed dynamically through control messages.
  • FIGURE 50 illustrates an embodiment for setting the parameters for "SpeedOrderSize" as controlled by the timers for Bot42. As shown, vertical lines indicate the times when trading is turned on and off respectively (8:00 and 17:00). From 8:10 to 8:30, the value of SpeedOrderSize is gradually increased from 0.5 to 1.0. From 16:00 to 16:40, the value is gradually decreased from 1.0 to 0.5.
  • FIGURE 51 illustrates an embodiment for the processing flow for Bot4X.
  • Timers are created, updated and deleted through inbound control messages. Control messages sent to the bots are created by individual timers. There are two types of timers
  • the ramp timer allows for a gradual change in the parameter over a specified time period.
  • the binary timer takes a discrete action at a single time point.
  • the binary timer sends a single message to the bot at the specified time.
  • timerObj createBinaryTimer(bot, ccyPair, parameter, time, value, recurring, id) ; addToList(timerObj, timerList) ;
  • the ramp timer sends a series of messages over the time period changing a numeric parameter at a specified rate.
  • timerObj createRampTimer(bot, ccyPair, parameter, startTime, duration, nlntervals, deltaT, startValue, endValue, recurring, id); addToList(timerObj, timerList);
  • FIGURE 52 illustrates Bot50 prices and parameters for each roll stack.
  • Bot50 is responsible for putting in orders into the roll stacks. Let day 1, day 2 and day 3 be the next three settlement dates. Then the roll stacks are rolll and roll2 where
  • the orders are initially submitted at the maximum size for each price, e.g., maxSizel for price BidPricel.
  • the prices are computed from the parameters FairValue, Radius, and the price deltas.
  • rolll moves orders from day 1 to day 2
  • roll2 moves orders from day 2 to day 3
  • X F fair value for the forward price for a spot-next contract
  • r x overnight repo rate for X
  • the interest rate parity relationship determines the forward price (see Hull, equation 3.14, p. 63):
  • the target prices are computed as follows:
  • Bot51 supersedes Bot50, and is responsible for putting in orders into the roll stacks. It is a clone of Bot20 with the following differences:
  • Bot51 determines fair value from overnight repo rates using the interest rate parity relationship. The radius is taken from a parameter value. • Prices for rolls are in 10 th 's of a basis point, not integer basis points (as with Bot20). • There is no check for order pick-off. • At the close of trading, Bot51 rolls orders from the roll2 stack to the rolll stack (as in Bot50). The roll2 stack is reinitialized.
  • rolll moves orders from day 1 to day 2
  • roll2 moves orders from day 2 to day 3
  • the value of the forward contract is -0.68 basis points.
  • FIGURE 53 illustrates an embodiment of the processing flow for Bot51.
  • FIGURE 53 depicts the processing flow for Bot51.
  • Bot51 responds to three events: an execution report, an updated parameter or a new fair value from BotlO. If the repo rate parameters are updated, or if a new fair value for the spot price is input, then Bot51 updates fair value for the rolls. After all events, Bot51 updates the stack thresholds, cancels orders outside the thresholds and refills the stacks.
  • FIGURE 54 illustrates the distribution of stacks for a roll.
  • Orders are generated randomly according to a random distribution as depicted above in FIGURE 54.
  • the generator is identical to that used in Bot20.
  • the thresholds in FIGURE 54 are computed from fair value and the radius from the parameters as follows:
  • the parameters bidGapl and askGapl in FIGURE 54 are used to constrain Bot51 to have orders within bidCancelThresh and askCancelThresh respectively.
  • Future Enhancements Future enhancements to Bot51 include:
  • FIGURE 55 illustrates an embodiment of the operation of Bot5X engines.
  • the Bot5X manages the stacks for manual trades submitted from the game pad and other devices.
  • the engine receives new order and cancel requests from Bot40.
  • For a cancel order the bot identifies which orders to cancel out of the stacks and sends an cancel order message to the appropriate stack.
  • Bot5X engine has no parameters. Parameters for manual trading are primarily contained in Bot40 and other trading interfaces.
  • FIGURE 56 illustrates an embodiment of the input and output messages and processing flow for Bot5X engines.
  • BOT50 Stack Cancel Message Subject "LEH.EFX.MLN.DEALS.IN.LEHMAN.BOT50.F” Message Format: BOT51 : DAR Cancel Message Subject: "Appia.MERLIN_FX.IN.LEH_EFX.D” Message Format: 1 -NY/1922975.1 82
  • Bot60 Price Filter Background FIGURE 57 illustrates an embodiment of price filter inputs, intermediate calculations and outputs.
  • FIGURE 58 illustrates an embodiment of how the radius multiplier for Bot70 decreases over the live span of an order.
  • FIGURE 59 illustrates an embodiment of how a time interval for an order is determined by the time and number of orders remaining.
  • FIGURE 60 illustrates an exemplary processing flow for Bot70.
  • FIGURE 61 illustrates a secondary processing flow for Bot70.
  • Order Book Cache cur S i z e Size of current order curPrice : Price of current order cur ID : ID of current order
  • cumSize cumSize + fillSize
  • curSize curSize — fillSize
  • Psuedocode Initialization of Secondary Engine The order book is imported from Bot41. The local variables are initialized as follows:
  • Inputs are the same as those for Bot50 except that Bot70 subscribe to normalized prices (like Bot20).
  • Cancel/New Order Message A new order message is sent when the total size for a price falls below the minimum threshold.
  • parameter refresh messages "LEH . MERLIN . CTRL . BOT7 O . ⁇ coiumn> . OUT »
  • FIGURE 62 illustrates an emobidment of how the radius multiplier for Bot70 decreases over the live span of an order.
  • FIGURE 63 illustrates how the time interval for an order is determined by the time and number of orders remaining.
  • FIGURE 64 illustrates an exemplary processing flow for Bot70.
  • FIGURE 65 illustrates a secondary processing flow for Bot70.
  • Order Book Cache OrderList [] Current list of active orders
  • ProcessCtrlMsgO changes to the parameters and to the target quantity are made through control messages
  • UpdateTargetScheduleO changes to the parameters and to the target quantity are made through control messages
  • UpdateDarPriceO update market data cache with new prices
  • ProcessDarExecRepO update order book with fills/cancels/rejects
  • Update ⁇ rders() main processing flow updating the active order book as necessary
  • Psuedocode Initialization of Secondary Engine The order book is imported from Bot41. The local variables are initialized as follows:
  • Inputs are the same as those for Bot50 except that Bot70 subscribe to normalized prices (like Bot20).
  • Cancel/New Order Message A new order message is sent when the total size for a price falls below the minimum threshold.
  • a cancel order message is sent when trading is turned off.
  • parameter refresh messages "LEH . MERLIN . CTRL . BOT7 O . ⁇ column> . OUT "
  • Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
  • Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have
  • Bid EUPJJPY Bid EUR/USD x Bid USD/JPY Ask EUR/JPY « Ask EUR/USD x Ask USD/JPY
  • FIGURE 66 illustrates a type 1 arbitrage.
  • FIGURE 67 illustrates a type 2 arbitrage.
  • the tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2.
  • the transaction cost and execution performance is not the same across all markets.
  • FIGURE 68 illustrates an exemplary processing flow for Bot8X.
  • Bot8X looks for an arbitrage opportunity.
  • FIGURE 69 illustrates a secondary processing flow for Bot8X.
  • FIGURES 68 and 69 The primary and secondary processing flows are shown in FIGURES 68 and 69.
  • OrderBook orderList list of open orders
  • arbBid arbitrage bid price
  • arblSide side of the order for the arbl currency pair
  • minRowlndex(double i ⁇ at[] [] , long j) returns row with the minimum value in column j
  • maxRowlndex(double mat[] [] , long j) returns row with the maximum value in column j submitOrder(enum market, enum orderType, enum symbol, enum side, double price, long side) : submit an order to the specified market
  • Bot8X subscribes to the following messages
  • Bot ⁇ X publishes the following messages:
  • Bot80 Bot80 subscribes and publishes to just DAR.
  • the price feed is the DAR feed
  • Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
  • Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have
  • Bid EUPJJPY Ask EUR/USD x Ask USD/JPY
  • FIGURE 70 illustrates a type 1 arbitrage.
  • FIGURE 71 illustrates a type 2 arbitrage.
  • the tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2.
  • the transaction cost and execution performance is not the same across all markets.
  • FIGURE 72 illustrates an exemplary processing flow for Bot8X.
  • Bot8X looks for an arbitrage opportunity.
  • FIGURE 73 illustrates a secondary processing flow for Bot8X.
  • FIGURES 72 and 73 The primary and secondary processing flows are shown in FIGURES 72 and 73.
  • OrderBook orderXiist list of open orders
  • arbBid arbitrage bid price
  • arblSide side of the order for the arbl currency pair
  • Bot8X subscribes to the following messages
  • Bot8X publishes the following messages:
  • Bot80 Bot80 subscribes and publishes to just DAR.
  • the price feed is the DAR feed
  • Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
  • Basics Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have Bid EUR/JPY » Bid EUR/USD x Bid USD/JPY Ask EUR/JPY « Ask EUR/USD x Ask USD/JPY An arbitrage opportunity arises if Bid EUR/JPY > Ask EUR/USD x Ask USD/JPY In this case, we can exploit the opportunity by selling the "primary" currency EUR/JPY and buying the "arb” currencies EUR/USD and USD/JPY. This is depicted in FIGURE 74. Similarly, we have an arbitrage opportunity if Ask EUR/JPY ⁇ Bid EUR/USD x Bid USD/JPY This situation is depicted in figure 75.
  • FIGURE 74 illustrates a type 1 arbitrage.
  • FIGURE 75 illustrates a type 2 arbitrage.
  • the tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2.
  • the transaction cost and execution performance is not the same across all markets.
  • FIGURE 76 illustrates an exemplary processing flow for Bot8X.
  • Bot8X looks for an arbitrage opportunity.
  • FIGURE 77 illustrates a secondary processing flow for Bot8X.
  • OrderBook orderList list of open orders
  • arbBid arbitrage bid price
  • arblSide side of the order for the arbl currency pair
  • minRowlndex(double mat[] [] , long j) returns row with the minimum value in column j
  • maxRowlndex(double mat[] [] , long j) returns row with the maximum value in column j submitOrder(enum market, enum orderType, enum symbol, enum side, double price, long side) : submit an order to the specified market
  • Bot8X subscribes to the following messages
  • Bot8X publishes the following messages:
  • BotSO Bot80 subscribes and publishes to just DAR.
  • the price feed is the DAR feed
  • the Bot90 engine computes the real-time volatility.
  • the method is based on the approach of estimating the individual volatilities using a time series model and back-out the covariances from the triangular arbitrage relationship. See [2] for methodological details.
  • FIGURE 78 illustrates an embodiment of how Bot90 estimates volatility for a specified time interval ⁇ .
  • Bot90 can compute different estimates across P subintervals.

Abstract

Objects of the invention comprise: (1) address limited price transparency; (2) address the market share domination held by the major banks; (3) address the failed competitive efforts of the past; and (4) address the cost problem associated with currency transactions. Various aspects of the invention address these issues. By way of example only, the software implementation of the present invention provides more price transparency to market action than previous systems; the non-deliverable forward aspect of the invention addresses the settlement cost issue; and the open-to-all-participants aspect of the invention addresses the oligopoly and profit structure issues. In one aspect, the invention comprises a non­-deliverable currency system open to all market participants with full market depth.

Description

METHODSANDAPPARATUSFORONLINEFOREIGNCURRENCYEXCHANGE
CROSS-REFERENCETORELATEDAPPLICATIONS
This application claims the benefit of U.S. Provisional Application No. 60/582,367, filed June 22, 2004. The entire contents of the above application are incorporated herein by reference.
FIELD
This invention relates to the field of currency trading.
BACKGROUND
The foreign exchange market has traditionally been dominated by a few of the world's largest commercial banks. This has created an oligopoly with a disproportionate share of the available global profit pool. Moreover, the processing of currency transactions can be costly. The system is top heavy with processing costs which, while highly beneficial to the banks, are detrimental to clients.
There is also very limited transparency in the market, due to the oligopoly. For example, the market provides to its users only limited information as to current bid and offer prices and the number of bidders and offerers at the current price.
A number of electronic foreign exchange systems have endeavored to address some of the problems presented by the traditional system. However, these systems typically suffer from a lack of liquidity and a failure to deliver a combination of features that are both comfortable for the foreign exchange trader to use and sufficiently cost effective to result in a shift of business from the traditional system.
SUMMARY Objects of the invention comprise: (1) address limited price transparency; (2) address the market share domination held by the major banks; (3) address the failed competitive efforts of the past; and (4) address the cost problem associated with currency transactions. Various aspects of the invention address these issues. By way of example only, the software implementation of the present invention provides more price transparency to market action than previous systems; the non-deliverable forward aspect of the invention addresses the settlement cost issue; and the open-to-all-participants aspect of the invention addresses the l-NY/1922896.1 1 oligopoly and profit structure issues. In one aspect, the invention comprises a non- deliverable currency system open to all market participants with full market depth.
Other aspects of the invention will be apparent to those skilled in the art. In particular, those skilled in the art will appreciate the various embodiments described in Appendix A, which is directed to bot aspects of the present invention, and Appendix B, which is directed to matching engine aspects.
One aspect of the present invention is directed to providing a user with stack displayed data regarding bid and offer prices, and stack displayed data regarding the number of bidders and offerers at a particular price. Such information can be presented to a user in graphical form (e.g., in a table with columns and rows) and all such data can be presented to a user simultaneously. By way of non-limiting example, the 10 highest bids and 10 highest offers can be presented to a user. This additional price and quantity data may enables a user to better gauge which bid or offer is appropriate for a particular trading goal. For example, and by way of comparison, a user viewing a system that only indicates 1 bid is at a disadvantage with respect to someone with the same trading goal presented with additional bid and offer data. Such disadvantage may force a user to speculate as to other bids, and cause the user to bid at a price higher than necessary in order to complete a transaction. Such bidding may, in effect, reduce the profitability of their trades.
Another aspect of the present invention is directed to providing a user with the ability to roll executed currency trades from one settlement date to another settlement date. For example, where a user has bought a product that is to mature in one day, but does not wish for that product to mature, the user may roll the current contract to a later settlement date. A roll transaction allows a user to roll a trade from one settlement date to another settlement date without having to book a buy and a sell.
Another aspect of the present invention is directed to matching orders between stacks. In an embodiment, and as described below as well as in Appendix B, a match engine is a message oriented, single threaded application that performs matching and automated market making based on specified rules. In various embodiments the functions performed by the match engine include: accepting incoming orders with quantity, price, and sender information; and performing market actions on the order (for example, inserting an order into an order book or canceling an existing order); and producing reports as confirmation of market actions: (for example, fill, partial fill, new order, cancel, etc). In an embodiment, 1 -NY/1922896.1 2 matching is done on a price-time priority basis. In an embodiment, if an incoming order has a corresponding matching order, it is matched instantly.
In an aspect, the present invention is directed to a computer-implemented method for currency exchange comprising electronically receiving data regarding a first plurality of currency bids and a first plurality of currency offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of bids and said first plurality of offers are associated with a first settlement date; electronically receiving data regarding a second plurality of currency bids and a second plurality of currency offers, said data comprising prices and quantities for said second plurality of bids and said second plurality of offers, wherein said second plurality of bids and said second plurality of offers are associated with a second settlement date; displaying said first plurality of bids and said first plurality of offers in a first arrangement corresponding to said first settlement date and displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers; and displaying said second plurality of bids and said second plurality of offers in a second arrangement corresponding to said second settlement date and displaying at least some of said prices and quantities for said second plurality of bids and said second plurality of offers; wherein said first arrangement and said second arrangement are displayed simultaneously to a user.
In various embodiments, said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for displaying offers corresponding to said first settlement date, and said second arrangement comprises a third column for displaying bids corresponding to said second settlement date and a fourth column for displaying offers corresponding to said second settlement date.
In an aspect, the present invention is directed to a computerized system for currency exchange comprising a communication component operable to receive currency exchange data regarding bids and offers for a first settlement date and a second settlement date; a display component operable to display said currency exchange data for said first settlement date in an arrangement corresponding to said first settlement date, and said currency exchange data for said second settlement date in an arrangement corresponding to said second settlement date, wherein said first arrangement and said second arrangement are displayed simultaneously to a user.
In various embodiments, said currency exchange data regarding bids and offers for 1 -NY/1922896.1 3 said first settlement date comprises a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity, and said currency exchange data regarding bids and offers for said second settlement date comprises a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity; said currency exchange data for said first settlement date is displayed in a first arrangement corresponding to said first settlement date, said first arrangement displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers, and said currency exchange data for said second settlement date is displayed in a second arrangement corresponding to said second settlement date, said second arrangement displaying at least some of said prices and quantities for said second plurality of bids and said second plurality of offers; said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for displaying offers corresponding to said first settlement date, and wherein said second arrangement comprises a third column for displaying bids corresponding to said second settlement date and a fourth column for displaying offers corresponding to said second settlement date; said communication component is operable to receive currency exchange data regarding bids and offers for a third settlement date; and said display component is operable to display said currency exchange data regarding bids and offers for said third settlement date in an arrangement corresponding to said third settlement date and at least one of price and quantity, wherein said currency exchange data for said third settlement date is displayed simultaneously with said currency exchange data for said first and second settlement dates; a currency exchange trade rolled from said first settlement date to said second settlement date results in said currency trade settling on said second settlement date.
In various embodiments the system further comprises a matching component operable to match at least one bid and at least one offer related to a particular settlement date; and a rolling component operable to roll one or more currency exchange trades from said first settlement date to said second settlement date.
In an aspect, the present invention is directed to a computer-implemented method for foreign currency exchange comprising electronically receiving data regarding a first plurality of roll bids and a first plurality of roll offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of roll
1 -NY/1922896.1 4 bids are associated with a first settlement date, and said first plurality of roll offers are associated with a second settlement date; displaying said first plurality of roll bids in a first arrangement corresponding to said first settlement date and at least one of price and quantity; displaying said first plurality of roll offers in a second arrangement corresponding to said second settlement date and at least one of price and quantity; and rolling a currency exchange trade from said first settlement date to said second settlement.
In an embodiment, rolling a currency exchange trade from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date.
In an aspect, the present invention is directed to a system for foreign currency exchange comprising a communication component operable to receive currency exchange data regarding one or more roll bids for a first settlement date and one or more roll offers for a second settlement date, wherein each of said one or more roll bids corresponds to a distinct currency trade, and each of said one or more roll offers corresponds to a distinct currency trade; a display component operable to display said one or more roll bids in an arrangement corresponding to said first settlement date and at least one of price and quantity, and said one or more roll offers in an arrangement corresponding to said second settlement date and at least one of price and quantity; and a rolling component operable to roll a currency exchange trade from said first settlement date to said second settlement date.
In various embodiments, said one or more roll bids each comprises a roll bid price and a roll bid quantity, and said one or more roll offers each comprise a roll offer price and a roll offer quantity; a currency exchange trade rolled from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date.
FIGURES
Fig. 1 depicts aspects of a foreign exchange currency trading system in accordance with an embodiment of the present invention;
Fig. 2 depicts further aspects of the system of Fig. 1;
Fig. 3 illustrates an exemplary price monitor display suitable for use in conjunction with an embodiment of the present invention;
1-NY/1922896.1 ^ Fig. 4 depicts a trade blotter display in accordance with an embodiment of the present invention; Fig. 5 depicts a stack view display in accordance with a preferred embodiment of the present invention; Fig. 6 depicts an order ticket display for; Fig. 7 depicts an account summary display; Fig. 8 depicts an account detail display for an exemplary account; Fig. 9 depicts an exemplary query trade history display; Fig. 10 depicts an exemplary query fixing history display; Fig. 11 depicts an exemplary customer information display; Fig. 12 is an exemplary list of accounts display; Fig. 13 is an exemplary account detail display; Fig. 14 is an exemplary settling position breakdown display; Fig. 15 is an exemplary trade detail display; Fig. 16 is a composite block/flow diagram of an embodiment of the present invention; Fig. 17 is a flow diagram illustrating preferred processing of a foreign currency exchange order; Fig. 18 depicts screen shots corresponding to the steps of Fig. 17;
Fig. 19 depicts additional screen shots corresponding to the steps of Fig. 17;
Fig. 20 is a flow diagram illustrating preferred operation of a roll trade; Fig. 21 illustrates price filter inputs, intermediate calculations and outputs; Fig. 22 illustrates an embodiment for the calculation of a radius; Fig. 23 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market; Fig. 24 illustrates a bot responsible for executing partial arbitrage orders that keep 1 -NY/1922896.! g certain non-deliverable markets in line with the DAR deliverable market; Fig. 25 illustrates a process flow for the bot illustrated in FIGURE 24; Fig. 26 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market; Fig. 27 illustrates a bot responsible for executing partial arbitrage orders that keep certain non-deliverable markets in line with the DAR deliverable market; Fig. 28 illusrates a BotlOX responsible for executing cash to roll arbitrage orders; Fig. 29 illustrates a process flow for BotlOX; Fig. 30 illustrates a type 1 arbitrage; Fig. 31 illustrates a type 2 arbitrage; Fig. 32 illustrates the processing Flow for Botl20; Fig. 33 illstrates the notional stacks of Bot20; Fig. 34 illustrates an embodiment for protecting against pick-offs on bids in the stack; Fig. 35 illustrates an embodiment for protecting against pick-offs on asks in the stack; Fig. 36 illustrates four notional stacks for Bot2X. In an embodiment, each stack can have a target distribution; Fig. 37 illustrates an embodiment for protecting against pick-offs on bids in the stack; Fig. 38 illustrates and embodiment for protecting against pick-offs on asks in the stack; Fig. 39 illustrates the operation of an embodiment of Bot22; Fig. 40 illustrates thresholds and parameters as described in connection with Bot22; Fig. 41 illustrates the flow of an embodiment of Bot22; Fig. 42 illustrates a type 1 arbitrage; Fig. 43 illustrates a type 2 arbitrage; Fig. 44 illustrates an embodiment of the processing flow for Bot3X; Fig. 45 illustrates a bot providing liquidity to a certain entity whenever that entity it is the constraining market; 1-NY/1922896.I J Fig. 46 illustrates a process flow for the bot illustrated in Figure 45;
Fig. 47 illustrates an embodiment for the flow of Bot40;
Fig. 48 illustrates a network diagram for Bot41;
Fig. 49 illustrates a network diagram for Bot41;
Fig. 50 illustrates an embodiment for setting the parameters for "SpeedOrderSize" as controlled by the timers for Bot42;
Fig. 51 illustrates an embodiment for the processing flow for Bot4X;
Fig. 52 illustrates Bot50 prices and parameters for each roll stack;
Fig. 53 illustrates an embodiment of the processing flow for Bot51;
Fig. 54 illustrates the distribution of stacks for a roll;
Fig. 55 illustrates an embodiment of the operation of Bot5X engines;
Fig. 56 an embodiment of the input and output messages and processing flow for Bot5X engines;
Fig. 57 illustrates an embodiment of price filter inputs, intermediate calculations and outputs;
Fig. 58 illustrates an embodiment of how the radius multiplier for Bot70 decreases over the live span of an order;
Fig. 59 illustrates an embodiment of how a time interval for an order is determined by the time and number of orders remaining;
Fig. 60 illustrates an exemplary processing flow for Bot70;
Fig. 61 illustrates a secondary processing flow for Bot70;
Fig. 62 illustrates an emobidment of how the radius multiplier for Bot70 decreases over the live span of an order;
Fig. 63 illustrates how the time interval for an order is determined by the time and number of orders remaining;
Fig. 64 illustrates an exemplary processing flow for Bot70;
Fig. 65 illustrates a secondary processing flow for Bot70;
1 -NY/1922896.1 g Fig. 66 illustrates a type 1 arbitrage; Fig. 67 illustrates a type 2 arbitrage; Fig. 68 illustrates an exemplary processing flow for Bot8X; Fig. 69 illustrates a secondary processing flow for Bot8X; Fig. 70 illustrates a type 1 arbitrage; Fig. 71 illustrates a type 2 arbitrage; Fig. 72 illustrates an exemplary processing flow for Bot8X; Fig. 73 illustrates a secondary processing flow for Bot8X; Fig. 74 illustrates a type 1 arbitrage; Fig. 75 illustrates a type 2 arbitrage; Fig. 76 illustrates an exemplary processing flow for BotSX; Fig. 77 illustrates a secondary processing flow for Bot8X; Fig. 78 illustrates an embodiment of how Bot90 estimates volatility for a specified time interval Δ; Fig. 79 illustrates the Calendar effects over the last five weeks of 2001 ; Fig. 80 illustrates the time of day, holiday and Asian daylight savings time effects; Fig. 81 illustrates an economic calendar effects; Fig. 82 illustrates an exemplary processing flow for Bot90; Fig. 83 illustrates an embodiment of BotBase; Fig. 84 illustrates an embodiment of a BotFilter; Fig. 85 illustrates an embodiment of a class hierarchy; Fig. 86 illustrates an embodiment with a primary and secondary instance of a Bot running on servers in physically different locations; Fig. 87 illustrates an embodiment for the initialization of a bot when a primary bot is not running; Fig. 88 illustrates an embodiment for the initialization and updating of state variables 1 -NY/1922896.1 Q for the secondary bot; Fig. 89 illustrates an embodiment for the initialization of the order book for a cold start of a primary instance of Bot41; Fig. 90 illustrates an embodiment for the initialization and updating of state variables for the secondary bot at different stages in the bot life cycle: initialization, maintenance and activation of the bot; Fig. 91 illustrates a Bot Overview in the present systems and methods; Fig. 92 illustrates an embodiment of price filter inputs, intermediate calculations and outputs; Fig. 93 illustrates an embodiment for the calculation of a radius; Fig. 94 illustrates an embodiment of a CustBot; Fig. 95 illustrates a processing flow for a price screen; Fig. 96 illustrates an embodiment of the processing flow for a quote; Fig. 97 illustrates an embodiment of the processing flow to construct a price from the OCR; Fig. 98 illustrates an embodiment of the flow for a deal filter; Fig. 99 illustrates an embodiment of a priority match; Fig. 100 illustrates an embodiment of a shift match; Fig. 101 illustrates an embodiment of an unmatched deal; Fig. 102 illustrates an embodiment of a nearest match; Fig. 103 illustrates an embodiment of the flow for the gridViewer client; Fig. 104 illustrates an embodiment of the flow for the ManualTrader engine; Fig. 105 illustrates a plot of a risk book; Fig. 106 illustrates a plot of a net risk; Figure 107 illustrates an embodiment of the main operating sections of a match engine; and Figure 108 illustrates an embodiment of the match engine cluster topography. l-NY/1922896.1 \Q DETAILED DESCRIPTION
Fig. 1 is a system diagram illustrating various aspects of a foreign currency exchange trading system 100. System 100 includes a first stack applet client 102, and second stack applet client 104 shown as running on a desktop computer. While two clients 102 and 104 are shown for ease of discussion, it will be recognized that the present invention can typically be deployed with any number of customers or users using any number of clients running on desktop computers, laptops, handheld computers or any other appropriate computer devices.
In Fig. 1, client 102 and the computer it is running on are connected by a private network connector 112 to a Financial Information Exchange (FIX) client server 106, as well as FIX Servers 122 and applet servers 124. As will be recognized, a single computer or server, for example, 122 or 124 shown in Fig. 1, can be representative of any number of servers. Client 104 and the computer it is running on are connected by a public network 114 to applet servers 124 and settlements web servers 126. Again, while a single web server 126 is shown for purposes of simplicity of illustration, multiple servers can be employed. Appropriate fire wall, encryption or other security measures also can be employed. Further, any suitable private, public, or dedicated network can be used (e.g., intranet, Internet, LAN, WAN, etc.)
Servers 122, 124, and 126 are connected to a trade management server (TMS) 132. In an embodiment, the rendezvous certified messaging (RVCM) is used as the communication protocol for communication between servers 112, 124, and 126 and the TMS 132 to ensure that customer orders make sense, are authorized, and meet all order criteria. TMS 132 serves as a front end for match engine 130 which additionally includes match engine servers 134, 136, and 138. Further details of order matching are provided below.
In an embodiment, TMS 132 is connected to market maker computers 142, 144, and 146. Such computers can be desktop computers, laptop computers, or smaller handheld computers. Again, an RVCM communication protocol can be employed. TMS 132 can also be connected to a memory 152 to store settlement data and a memory 154 to store market trade data, both of which memories are shown as databases. It will, however, be recognized that other memory devices for storing such data may be utilized. TMS 132 can also be connected to a bank of RISC processors 158 to provide trade processing (such as rollover 1 -NY/1922896.1 \ \ 87
transaction processing, settlements, etc.)
Fig. 2 shows further details of a preferred implementation of parts of the system 100 of Fig. 1. To prevent data loss, a redundant system is envisioned (e.g., a system with components located in two locations, such as New Jersey and New York). In addition to the system components shown in Fig. 1, the components of Fig. 2 also can include firewalls 118, model engines 140, infrastructure service servers 150, and databases 160 which would include databases 152 and 154 as well as associated database processing components. The model engines 140 enable and support the execution of mathematical strategies based upon one or more external data sources, such as trade data, government reports, interest rates, weather reports, and the like.
Turning to the operation of the system 100, trade orders preferably are entered by customers using stack applet clients 102 and 104. System 100 advantageously has great flexibility in the variety of ways in which it supports customer use of the system. In an embodiment, trading software can be downloaded remotely from applet servers 124 for use during a particular trading session. This approach gives a customer the flexibility to trade from anywhere by logging on with a user ID and a password to access the system. Thus, customers do not need to use a particular computer or be in a particular location to access the system. Further, a traveling customer need not call back to the office and have someone carry out voice instructions on a dedicated machine. Rather, a customer can access the applet client 124 through any suitable computer connected to an appropriate network (such as the Internet), sign in using suitable security measures, and then download software (e.g., JAVA applets) which then are stored on his computer.
In an embodiment, a user can access the system and enter trading orders using custom client software supported by a client server, such as server 106 of Fig. 1. The downloaded client can be installed on a hard drive of a computer to be used for trading purposes. A regular confirmation will be preferably made upon sign-in, confirming that the most current software build is being employed. Automatic updating can be implemented where it is determined that the most current software is not in use. Safeguards preferably are employed to ensure that only licensed equipment is allowed to download the system software, so as to prevent unauthorized duplication and possible misuse thereof.
In various embodiments (e.g., with either single session applets or custom client software,) web pages or screen shots of displays, such as displays 300-1500 depicted in Figs. 1-NY/1922896 1 12 22187
3-15, can be used by clients to enter orders, check account status, and the like, as further explained below.
Fig. 3 shows an exemplary price monitor display 300 for use in connection with the present systems and methods. In display 300, the three major currency pairs (Euro (€) and U.S. dollar ($) (EURAJSD pair 310, U.S. dollar and Japanese yen (¥) (USD/JPY) pair 320, and Euro and Japanese yen (EUR/JPY) pair 330) are shown. Each pair has its respective bid price (312, 322 , and 332), its respective ask or offer price (314, 324, and 334), and its respective contract closing date (316, 326 and 336). Beneath bid and offer blocks 317 and 318, 327 and 328, and 337 and 338, the number of bidders and offerors at the current bid and offer prices are shown. For example, there are three bidders at the current bid price for EURAJSD and one offeror at the current price. The above information is familiar to users of the EBS interdealer platform.
In addition, display 300 includes blotter button 340, stack button 350, and ticket button 360 near the top of the display, as well as exit button 370. Each currency pair has its own respective stack button (319, 329, and 339) located beneath the current bid and offer prices. The function of these buttons is explained below in connection with the discussion of Figs. 4-6.
The following discussion relates to Fig. 4. When a user wants to see trade blotter display 400 of Fig. 4, she selects that display by clicking on trade blotter button 340 in the price monitor display 300. In the trade blotter display 400, details for all deals are displayed. The user can scroll up or down or left or to view trade blotter details. To focus on only open deals, the user can click on an Open Deals button 402. To focus on closed deals, the user can click on a Close Deals button 404. To return to an all deals display from an open or close deals display, the user clicks on All Deals button 406. In the exemplary display 400, deal details are arranged in columns 405-411 : trade date 405, state 406, symbol 407, side 408, original price (OrigPx) 409, average price (AvgPx) 410, and last price (LastPx) 411. Additional relevant information can be displayed by adding additional columns. By way of non-limiting example, such additional columns may include original quantity (OrigQty), last quantity (LastQty), filled, account number (Account), and type. With custom software on a server, such as server 106 of Fig. 1, a user can customize a trade blotter display to suit his specific needs. It will be recognized that a Java applet approach can allow a system operator to readily update or upgrade the display to adapt it to other types of trades or to address l-NY/1922896.1 13 87
customer desires.
Referring back to Fig. 3, clicking on stack button 350 causes stack display 500 to be displayed. In an embodiment of display 500, stack data can be displayed for the EUR/USD pair as a default. By clicking on drop down menu 502, the user can select stack data for the USD/JPY, EUR/JPY, or other defined currency pairs. The user can also click on the individual stack buttons 319, 329, or 339 to go directly to the stack data display for a desired currency pair.
A date block 504 displays the current day's date. A block 506 shows the status of trading. In an embodiment, block 506 can also indicate a fixed exchange price for contracts closing that day. As seen in display 500, the active price is $1.13565 $/€. A time to settlement block 508 shows the hours and minutes to settlement and a time to close block 510 similarly shows the hours and minutes to close. An account block can also be incorporated to show a default account name and can include a drop down menu to display other account names where multiple accounts are being traded.
Display 500 preferably includes stack data display blocks 520, 530, and 540 for contracts settling on three different days (in this example, July 8th, 9th, and 10th). The middle block (530) is for the spot trading date, block 520 is for spot day - 1, and 540 is for spot day +1. Taking stack data display block 520 by way of example only, there are two columns, indicating bids and offers. As shown, there is one bid at the current bid price of 1.1355 (indicated as "55" under "BID") and 7 offers at the current price of 1.1358 (indicated as "57" under "OFFER"). Below the bid section are two columns with additional bid data: block 523 shows quantity (QTY) in a column 522 and price (PX) 524 in a column 525. Below the offer section in block 520 are two columns with offer data, in columns for price 526 and quantity 527. These aspects are both new to online foreign exchange currency trading and highly advantageous, as discussed in greater detail below.
As shown in Fig. 5, each display block 520, 530, and 540 can have corresponding bid and offer sections that contain columns indicating quantity and price, as described in connection with block 520. For example, block 530 depicts 1 bid at 1.1356 ("56") and two columns of quantity and price, as well as 7 bids at 1.1357 with two columns of price and quantity.
Each order processed by the system 100 may be assigned a sequential number and placed in a stack of pending orders, based upon the time at which it is received and the 1 -NY/1922896.1 14 5 022187
competitiveness of the order. The above displays provide a tremendous amount of new information not previously available to a user considering whether to make a bid or offer, and enables a user to track the status of a bid or offer in a manner not previously possible. Analyzing the bid stack data 522, a user can see the following information. First, one bid was placed for one contract at the current bid price. An additional bid was placed for five contracts at 1.1353. One bid was placed for two contracts at each of 1.1352, 1.1350, 1.1349, and 1.1348. One bid was placed for 4 contracts at 1.1348. Two bids were made for 3 contracts each at 1.1347, and one bid was made for two contracts at 1.1346.
Display block 520 includes similar offer stack data 524, and display blocks 530 and 540 have their own bid and offer stack data 532 and 534, and 542 and 544, respectively. While in the display 500 only ten orders are shown in each stack, it will be apparent that more or less orders can be displayed as desired.
As will be recognized, the additional price and quantity data enables users to better gauge which bid or offer is appropriate for a particular trading goal. For example, and by way of comparison, a user seeking to buy or sell ten July 8 contracts, using a system that only indicates that there is 1 bid at 1.1355 and 7 offers at 1.1358, is at a disadvantage with respect to someone with the same trading goal presented with the stack data shown in display 500.
Further, a user's own orders preferably are highlighted in the stack data, allowing the user to track and evaluate the competitiveness of his order, as well as to gauge the likelihood of it being filled. The placing and tracking of these orders also increases the liquidity of the market provided by the system. Additionally, orders can be color coded based on price or quantity, to expedite information assimilation. As will be recognized, where bids and offers cross, the system can be configured to automatically execute the trade. Such executed contracts preferably are no longer displayed on the stack. Instead, executed contracts preferably are shown in a separate open transactions window (e.g., a trade blotter window as shown in Fig. 4).
Also depicted in Fig. 5 are roll blocks 550, 560, and 570. In the event that a user does not wish to close or settle his transactions on a particular day, he may roll his open transactions into another day. Block 550 shows 10 bids at .00005 and 10 offers at .00005. The quantity (551) of each bid is shown in column 552. Similarly, the price (553) of each bid is listed in a column 554. Columns 555 and 556 illustrate the price and quantity for roll offers. As will be recognized, roll block 550 pertains only to rolling spot -1 to spot (i.e., 1 -NY/1922896.1 15 rolling July 8 transactions into July 9 transactions).
As shown in block 550, a user wishing to "purchase the roll" from July 8 to July 9 can place her bid price for a particular quantity. By way of example only, the roll market compares the July 8 outright market to the July 9 outright market. If a user is long for the July 8 EUR/USD currency non-deliverable forward ("NDF"), and wishes to extend the position to the July 9 NDF, he can effect this type of transaction by "buying the roll." The current offer in the July 8/July9 roll is .00005. So if a user is long 10 EUR/USD NDFs at 1.1355, and he buys the roll at .00005, his new position would have an effective rate of 1.13555. The roll trade, however, requires that some amount of July 8th NDFs be sold and the same amount of July 9th NDFs be purchased.
By way of non-limiting example, if a user bought an NDF that would mature in one day, but doesn't want it to mature and also doesn't want the cash value, the user can roll it from its current contract to a different contract (i.e., roll from current maturity to next maturity, or two days maturity, etc.). For example, if the user were to buy Yen on Monday, the Yen would go into the user's account on Wednesday as Yen trades typically settle in two days. If the user did not want to take possession of the Yen, he could roll the trade to the following day; namely, he could sell it back and then buy it back for value on Thursday without taking possession of the Yen. The trade also doesn't affect the user's account because the trades are net-settled.
The rolling a trade may prevent the trade from ever maturing. The cost of accomplishing that transaction is the difference in the cost of the commodity today minus the cost of it tomorrow. Thus, if it appreciates one penny in value, the cost to roll it would be a penny (in this example, the user would be charged a penny); if it depreciates one penny in value, the user's account would get credited a penny upon execution of a roll. A roll transaction allows a user to roll a trade from one day to the next without having to book a buy and a sell. This capability creates a roll market.
As will be recognized, a roll market allows for a number of different types of trades. By way of example only, these can include: buy or sell on day 1, buy or sell on day 2, buy or sell on day 3, buy or sell a roll trade between value days 1 and 2, buy or sell a roll trade between value days 2 and 3, buy or sell a roll trade between days 1 and 3, and buy or sell a roll to spot cash.
By way of example, assume each stack is selling a different commodity. For 1 -NY/1922896.1 \β simplicity, say stack 1 is selling a blue commodity, stack 2 is selling a red commodity, and stack 3 is selling a green commodity. On day 1, the user buys a blue commodity (which can be shown in a left hand stack on a display screen). The user decides he wants to own the red commodity; so he enters into a roll trade where he buys a roll. (Effectively, what gets booked on exchange is: sell a blue commodity and buy a red commodity). If the user then decides he doesn't want the red commodity, but instead wants the green commodity (which can be shown in a right hand stack on a display screen), he enters into another roll trade selling the red commodity and buying the green. The user can also sell a roll trade. If he doesn't want the green commodity anymore, he can sell his position in the green and buy a position in red. The cost of the roll trade is the difference in price between the green and red commodities. Thus, the user can replace the green with the red without having to sell green and buy red. As will be recognized, roll data and stack displays can be displayed to a user simultaneously.
In an embodiment, a roll trade is arbitrage free. If the difference between two stacks is not the price of the roll trade, there would be an arbitrage opportunity.
The forward value of a currency is relative to the interest rate in that currency. Thus, if a user knew the spot rate of the currency (e.g., Yen), and the interest rate of that currency, the user could estimate what the one day and three day trade would be. Because the spot market for Yen is two days forward, three days forward would be the spot price of Yen plus one day's interest on Yen. (This is a result of interest rate parity, which provides that if the user were to buy Yen today and invest it in Tokyo, at the end of the year the user would end up with the same amount as if he invested in dollars. If interest rates are high in Tokyo and low in the US, the user would get fewer dollars back for Yen a year from now. Because the user made more on the interest, he would lose it in the exchange rate.) Thus, regardless of the currency at issue, the difference in the one, two, and three day stacks is the interest rates in those currencies.
If a user wanted cash, he could roll the center stack- the spot non-deliverable - into spot cash. This creates an arbitrage-free market between the center stack and the cash market. (As will be recognized, if the center stack looked cheap or rich compared to cash, someone would start trading and it would correct itself). Thus, the center stack is tied to cash (arbitrage-free), and the side stacks are pegged to the center stack; the roll markets ensure that the side stacks are arbitrage free.
An NDF product only has value on the exchange on which it was traded. Thus, it is 1-NY/1922896.1 ' \J T/US2005/022187
important that the exchange on which the user purchased the product is open when the user wants to trade the NDF. Because the stacks are tied to the cash market - a 24 hour market, and it is arbitrage free exchange, it is important that the market be open when the cash market is open.
Also shown in Fig. 5 is the spot +1 roll stack (i.e., July 10 stack) 570. This block also illustrates 10 bids at .00005 and 10 offers at .00005. Further shown are quantity and price for the bids (571 and 572 respectively) as well as price and quantity for offers (575 and 576 respectively). Also shown in Fig. 5 is the spot roll stack 560 (i.e., July 9 stack). As described above, this stack allows users to roll to cash in an arbitrage free environment.
In various embodiments, and as described in Appendix A, any number of computer engines (bots) can be implemented to perform various tasks related to the systems and methods described above. For example, a matching engine can be implemented to maintain an order book and to match orders between buyers and sellers (e.g., a matching engines can determine when a client order crosses the market, and can automatically execute the order). Various stack displays of the above systems and methods can represent market making offers to buy/sell. In such instances, when bids/offers cross into a different stack, the trade will execute. When there are orders for the same price, the buyer and seller are notified and the trade is moved into the executed stack. As will be recognized, order entries in the stacks may be prioritized by time/price matching (e.g., if there are two orders in the stack for 45, the earliest in time will execute first).
Further, where no user orders are currently in the stacks, a priming engine can be used to prime stacks with a broker's orders. By way of non-limiting example, other engines can maintain price spreads, maintain stack depths, search for cross currency arbitrage opportunities, adjust the liquidity of the broker's market, isolate orders from certain users, manage orders, and manage roll markets.
Preferred matching engine details are provided in Appendix B.
Returning to price monitor display 300 of Fig. 3, if the user clicks on ticket button 360, then an order ticket display such as display 600 of Fig. 6 is displayed. This exemplary order ticket display preferably includes a user account block 602 with a drop down menu for additional user accounts, a date block 604 with a drop down menu enabling a user to select a contract date by checking on the desired contract date, and a currency pair block 606 with a drop down menu enabling a user to readily select the desired currency pair. A bid or offer 1-NY/1922896.1 18 T/US2005/022187
block 608 allows the user to select the desired side of the transaction.
Price block 610 and quantity block 612 allow the user to establish a price and quantity. An update price (UpdatePx) block 614 can be clicked to update the price for an existing order using the price block 610 to reflect a changed judgment on the correct price, to reflect a change in market conditions, or the like. Ready block 616 allows a user to confirm that the order is correct and ready to submit and send block 618 allows a ready order to be submitted. Close block 620 allows a user to close the active order ticket display window. Blotter block 622 allows the user to display the blotter screen, and Cancel block 624 allows the user to cancel any activity associated with the current ticket window.
A ticket display such as that depicted in Fig. preferably 6 is the primary device for entering orders. The account, date, currency pair, price, quantity, and the intention to bid or offer can be controlled through the blocks displayed.
Figs. 3-6 and their corresponding descriptions collectively illustrate tools utilized by users to learn about market conditions, open and close orders, and roll in and out of positions. Figs. 7-15, on the other hand, illustrate preferred account management and settlement tools related to the present systems and methods.
Starting from an account summary display 700 (see in Fig. 7), a user can readily navigate through one or more screens to learn pertinent account details and advantageously manage one or more accounts. Exemplary display 700 provides account summary data arranged in columns by account number 702, account name 704, realized profit and loss (Realized P & L) 706 and unrealized profit and loss (Unrealized P & L) 708. Navigation to further account details can be readily accomplished utilizing menu select buttons, such as Account 710, Trade History 712, Fixing 714, Customer 716, Tools 718, Summary 720 or Info 722 (discussed below in connection with Figs. 8-15). In addition, by clicking on a particular account number, such as account number 724, LBOOLOOl, or account number 726, LEH_ARB_SSRUSD/JPY, a user can navigate to a display showing further account details.
A user who wants to see further account data and clicks account menu select button 710. This selection results in account display 800 of Fig. 8 being displayed. Display 800 shows account details for the first listed account number 724, LBOOLOOl. Paging down allows details for the remaining accounts to be displayed in a similar manner. In the exemplary display 800, account details are displayed in columns as follows: security 802, 1-NY/1922896.1 19 position 804, average price 806, current market price 808, realized profit 810 and unrealized profit 812. It will be recognized that other formats with additional or other information would be suitable, depending upon the user.
Returning to display 700, if the user had clicked Trade History button 712, then Query Trade History display 900 of Fig. 9 would be displayed. Using a trade number block 902, a user can drill down to the specific details of the history of a specific trade by entering (or selecting) a specific known trade number. Account currency pair information can be selected using a drop down menu 904. Date ranges can be specified using start and end dates 906 and 908, or a period can be selected from a period drop down menu 910. Security pair types can be selected by checking one of the pair boxes 912, and the output format can be selected using a format drop down menu 914. The query is submitted by clicking a submit button 916.
If the user had clicked Fixing button 714 on display 700 of Fig. 7, then Query Fixing History display 1000 of Fig. 10 would be displayed. As was the case for display 900, date range and period searches can be conducted by clicking an appropriate bullet and using start and end dates 1006 and 1008, or a period drop down menu 1010. A security type can be selected using a security selection menu 1012, and the query can be selected by clicking submit button 1016.
If the user had clicked Customer button 716, then customer information display 1100 of Fig. 11 would be displayed. In the exemplary display 1100, customer contact details such as mailing address, phone, and email address are shown. Settlement instructions for a number of different accounts may be displayed.
With respect to Tools button 718 of display 700 of Fig. 7, account, preference, and user definable tools will be accessible from a web page displayed in response to clicking this button.
If summary button 720 is clicked, then a summary list of accounts display 1200 shown in Fig. 12 is displayed. Accounts are listed on display 1200 in account number 1202 and account name 1204 columns.
Fig. 13 is an exemplary list of account details display 1300 reached by clicking on specific account name 726 of display 700 of Fig. 7.
Fig. 14 shows a settling position breakdown display 1400 providing settling position 1-NY/1922896.1 20 details for the account 726 whose account details are shown in Fig. 13.
Fig. 15 shows a trade detail display 1500 for a specific trade 1502, trade number 22810386.
As will be recognized, addition functionality can be implemented in connection with Figs. 7, such as providing users with an independent settlement mechanism to settle orders placed in connection with the embodiments described above. For example, NDFs that settle on a particular date can be settled through such an independent settlement mechanism. Independent settlement mechanisms can potentially reduce millions of dollars from traditional settlement process costs. This cost savings can provide a liquidity edge due to lower marginal transaction costs.
Fig. 16 is a composite block/flow diagram illustrating preferred configuration and operation of an embodiment of the present invention. Shown in Fig. 16 are a client 1600, server 1610, client account 1620, exchange account 1630, trading servers 1640, and market 1650. A client may submit an order to the server 1610 through connection 1602. This preferably is a two way connection, allowing the server to transmit messages to the client. Server 1610 can represent any trading market can be a single server, or a plurality of servers, including the matching engine described above.
Server 1610 is tethered to the cash market 1642 through the trading servers 1640. These can be bots, and their functionality is described in Appendix A. In an embodiment, the bots listen to all orders, and when they recognize that an order can be filled in the cash market, the bot is operable to fill that order in the cash market.
A preferred process of ordering and filling orders is described in more detail below. Suppose client 1600 submits an order for 5 Euros to server 1610. The order gets filled via by the exchange account 1630 and the client is notified via connection 1602. After client order is filled, the client account 1620 is updated via connection 1614 and the exchange account gets debited through connection 1616. In an embodiment, client account 1620 and exchange account 1630 can be connected via connection 1622 to facilitate order completion. Here, the client account will then be + 5 Euros and the exchange account will be - 5 Euros.
As described above, trading servers 1640 "see" that an order has been made by the client and filled by the exchange server for 5 Euros, and can then go to the cash market and obtain 5 Euros. An order is placed in the cash market for 5 Euros and the order is filled via
1-NY/1922896.1 21 connection 1642. When the trading server's order is filled, the trading server sends an order to server 1610 via connection 1612. This order gets filled and the exchange account is updated + 5 Euros.
As will be recognized, server 1610 can implement the order book, stacks, rolling stacks, settlement methods, and account information described above. As will be further recognized by those skilled in the art, the components and functionality of Fig. 16 can be implemented in accordance with the description provided in connection with Fig. 1.
Fig. 17 is a flow diagram illustrating the operation of an embodiment of the present systems and methods. As shown in Fig. 17, in step 1702, a user opens a trade window. The trade window allows a user to view current trading information, and also allows a user to access various displays and foreign exchange functionality as described above. In an embodiment, such a window can be a price monitor window as described in connection with Fig. 3. Although a user may elect to open windows in any particular order, flow is described in an arbitrary order below (e.g., flow may proceed to step 1704, 1706, or 1708,' as the user desires). Additionally, links may be provided to enable a user to move from one window to any other window. For example, direct links may be provided in each window 1702, 1704, 1706, and 1708 enabling a user to switch to any other window. As will be recognized, a user can omit any steps, revisit any windows in any order, or return to the trade window at any time.
In an embodiment, one display window can be configured to display the information contained in windows 1702, 1704, 1706, and 1708. In an embodiment, the information contained in windows 1702, 1704, 1706, and 1708 may be divided between any number of display windows. As will be recognized, the present systems and methods are capable of presenting the information in numerous ways.
In step 1704, the user opens a stack window. Such a window can contain information as described above in connection with Fig. 5. As described in detail above, the stack information can contain a bid section and an offer section, with each section containing two columns of information related to a particular settlement date. In an embodiment, the two columns contain sorted price and quantity information. Such a window can contain stack data for any number of settlement days. This information allows a user to determine whether to place an order, and if so, at what price to place the order.
For example, the stack data can contain data for the spot settlement day, or may 1 -NY/1922896.1 22 contain information for the spot settlement day -1, or for the spot settlement day +1, etc. Further, the stack window can contain data for two days (e.g., spot and spot -1, spot and spot +1, or spot -1 and spot +1). The stack window can be configured to display data for any number of days (e.g., 3 days (spot, spot -1, and spot +1)). As will be recognized, the stack window can be configured to display additional information as discussed above, and each window may be configured to display links to other windows. Prices and quantities for each displayed settlement date provide relevant trading information to users, enabling them to determine whether to place orders for a particular settlement date, and where their orders would fall in the displayed stack. With this information users can better gauge which order is appropriate for a particular trading goal.
As discussed in connection with block 1712, where a user has previously placed an order, including on previous days, stack window 1704 can display and highlight the user's current position in the stack.
In step 1706, the user opens a ticket window. Details of a preferred ticket window are discussed in connection with Fig. 6. In an embodiment, the ticket window is the mechanism used to place a particular order. Such windows can provide a user with the ability to select a currency pair, settlement date, price, quantity, and type of order to be placed. After selecting relevant criteria, the user places an order, which is submitted to the system. The order window can also provide a mechanism to cancel an order. As discussed above, the window may also provide links to other windows.
In step 1708, the user opens a trade blotter window. Details of a preferred trade blotter window are discussed above in connection with Fig. 4. As discussed above, the trade blotter window allows a user to view all orders, including open, closed, and cancelled orders. Certain relevant information about the orders is displayed in columns in the display window. If a user has no open trades, the trade blotter will have no trades to display. As discussed in connection with step 1716, where a user has previously placed an order, including on previous days, the trade blotter window 1708 can display the user's current orders.
When a user is ready to place an order, the user opens a ticket window (1706), inputs his criteria, and submits his order to the system (step 1710). After orders are placed, steps 1712, 1714, and 1716 may be performed. As discussed above, although a user may elect to open windows in any particular order, flow is described in an arbitrary order below (i.e., flow may proceed to step 1712, 1714, or 1716, as the user desires). Links may be provided to 1 -NY/1922896.1 23 enable a user to move from one window to any other window. As will be recognized, a user can omit any steps, revisit any windows in any order, or return to the trade window at any time.
In step 1712, a user opens a stack window. Details of a preferred stack window are discussed above. Where a user has an open order, the relevant information is displayed in the stack. In an embodiment, the user's order is highlighted on the screen. As will be recognized, the stack can sort data based on price and quantity; accordingly, the user's order will be displayed in the appropriate location in the stack. As orders are filled, placed, or cancelled, the user's new position will be displayed automatically or via a manual refresh.
In step 1714, a user opens a trade window to place an order as discussed above.
In step 1716, a user opens a trade blotter window to view his current orders. As discussed above, the trade blotter window is configured to display all orders for a particular user.
A user may continue to view that stack, place orders, or review the trade blotter as desired. As will be recognized, orders may settle on a particular day. Where a user does not wish to settle her open orders, she may purchase a roll as described in detail above and below in connection with Fig. 20.
Fig. 18 is block diagram depicting displays corresponding to steps of Fig. 17. As shown in Fig. 18, a user can open a trade window 1802 (corresponding to step 1702). In this example, the trade window displays relevant trading information to the user for the three major currency pairs, and also provides links to the various display windows described in connection with Fig. 17. Here, the user selects the stack display 1804 (corresponding to step 1704). As shown, display 1804 illustrates the current bid and offer stacks, with columns indicating the prices and quantities for all bids and offers. Based on this information, the user elects to place an order.
The user may open a ticket window 1806 (corresponding to step 1706). As shown, the user elects to place an offer at a price of 1.1236 for a quantity of 10,000. When a user clicks send, the order is sent to the system.
Fig. 19 is a block diagram depicting displays corresponding to other steps of Fig. 17. A user can open a trade window 1902 (corresponding to step 1702). In this example, the trade window displays relevant trading information for 5 different currency pairs. As will be 1 -NY/1922896.1 24 recognized, the trade window can be configured to display any number of currency pairs. Trade window 1902 also provides links to the various display windows described in connection with Fig. 17. Here the user selects the stack display 1904 (corresponding to step 1704). In this example, the user waits approximately 10 minutes, and a reviews a subsequent stack window 1906. As will be recognized, this window may automatically update or be manually refreshed. As shown, the current prices have changed between display 1904 and 1906.
Displays 1908-1914 illustrate an order flow where a user cancels a first offer and submits a second offer that is accepted (corresponding to steps 1706 and 1710). In connection with display 1908, a user modifies the order window, and in connection with display 1910 sends an order that is acknowledged. In connection with display 1912, the user cancels the order, and in connection with display 1914 the user places a subsequent order.
In connection with display 1916 (corresponding to step 1716), the user reviews the trade blotter window. As shown, the user's previous cancelled order and the accepted order are displayed.
Fig. 20 is a flow diagram illustrating preferred operation of a roll trade. Such trades were previously unavailable in the foreign exchange market. As discussed above, by providing a rolling mechanism, new roll markets have been created.
In step 2002, a user places an order. Placing an order is described in detail above. Each contract has a settlement date (also called a spot date, or spot settlement date). In the foreign exchange market, orders generally settle within two days of the date on which the order is placed. For example, if a user orders ¥ 10,000 on a Monday, the Yen will normally be delivered to the user's account on Wednesday.
As discussed above, a user may roll any open contracts into another settlement day. In step 2004, a user has orders that will settle 1 day before the current spot date (spot date -1). For example, if a user places an order on Monday, the spot date would be Wednesday, and the spot date -1 would be Tuesday. Accordingly, if a user had any open contracts that would settle on Tuesday, he could roll those contracts into another settlement date. If a user wishes to settle, flow continues to step 2010, and the orders would settle on their settlement date. If a user does not wish to settle, flow proceeds to step 2012. If the user wishes to roll, flow proceeds to step 2018. If the user does not wish to roll, flow continues to step 2004. In an embodiment, a user can configure the system to automatically settle or to automatically roll 1 -NY/1922896.1 25 22187
open trades. In an embodiment, open orders automatically settle on the settlement date. In an embodiment, open orders automatically roll to the next settlement date.
As discussed above, roll transactions allow users to roll trades from one day to the next without having to book a buy and a sell, thereby creating a roll market (providing a roll for users roll contracts settling on spot date -1 to the spot date). As such, bids and offers for spot date — 1 are displayed in the stack viewer, and users can place orders for contracts settling in one day, rather than contracts normally settling in two days. Further, users can place orders for rolling contracts from one settlement date to another date. These displays are discussed above in connection with Fig. 5.
A roll market allows for a number of different types of trades. By way of example only, these can include: buy or sell on day 1 (spot date - 1), buy or sell on day 2 (spot date), buy or sell on day 3 (spot date + 1), buy or sell a roll trade between value days 1 and 2, buy or sell a roll trade between value days 2 and 3, buy or sell a roll trade between days 1 and 3, and buy or sell a roll to spot cash. As will be recognized, a user may purchase a roll from spot - 1 to spot + 1.
In step 2006, a user has orders that will settle on the spot date. The user may elect to do nothing for one day, whereby flow would continue to step 2004. In an embodiment, a user may wish to settle on the settlement date, and flow would continue to step 2010.
A user also may elect to purchase a roll to spot + 1 (step 2014). If so, flow continues to step 2018, whereby a roll from spot to spot + 1 has been purchased. Additionally, as described above, a user may elect to roll open contracts to cash.
Similar to the discussion above, where a user has orders that will settle on spot + 1 (2008), the user can elect to settle (2010), do nothing (flow would proceed to step 2006), or roll his trades (2016). Although the spot +2 is not shown in the stack view of Fig. 5, it may be configured to display any number of days.
While the present invention has been illustrated and described above regarding various embodiments, it is not intended to be limited to the details shown, since various modifications and structural changes may be made without departing in any way from the spirit of the present invention. Moreover, features described as present in a particular embodiment (e.g., "in an embodiment" or "in another embodiment") also may be present in some (or all) other embodiments.
I -NY/1922896.1 26 Appendix A -NY/1922975.1 Price Engine: Bot10 Filter Background
FIGURE 21 illustrates price filter inputs, intermediate calculations and outputs.
Algorithm
FIGURE 22 illustrates an embodiment for the calculation of a radius.
Variables FVt = fair value at tick t Rt = value of radius at tick t Bt = (working) bid price At = (working) ask price bidType = type of bid price: primary or arbitrage askType = type of ask price: primary or arbitrage BOt = bid price for the primary currency pair AOt = ask price or the primary currency pair Blt = bid price for the arbitrage currency pair 1 Alt = ask price for the arbitrage currency pair 1 B2t = bid price for the arbitrage currency pair 2 A2t = ask price for the arbitrage currency pair 2 C = 10A-nDigits
Initialization R0 = parm.RadiusMaxSpread * parm. SpreadTol * C; FV0 = PRI CE-BLANK; B0 = PRICE_BLANK; A0 = PRICEJBLANK;
Calculation of Arbitrage Prices if(B0t = PRICE_BLANK) B0t = SMALL_NUMBER; if(A0t = PRICE_BLANK) A0t = BIG_NUMBER;
if (arbFilter=="on" ) { if (Bit = PRICE_BLANK) Blt = SMALL_NUMBER; if (Alt = PRICE_BLANK) Alt = BIG_NUMBER; if (B2t = PRICE_BLANK) B2t = SMALLJSTOMBER; if (A2t = PRICE_BLANK) A2t = BIG_NUMBER;
if (ARB2_ACTION == "same" ) { arbB = Blt * B2t ; arbA = Alt * A2fc ; } else { arbB = Bit / A2t; arbA = Alt / B2t; } if (arbB-arbBidDelta > B0t) { Bt = arbB; bidType = "arbitrage" ;
l-NY/1922975.1 2
Figure imgf000031_0004
Calculation of Radius The radius at tick t is computed by
Figure imgf000031_0001
Calculation of Fair Value The fair value at tick t is computed by
Figure imgf000031_0002
Calculation of Broadcast The broadcast is taken as fair value plus/minus the radius times a scale factor rounded to the nearest whole price. A broadcast is only output if fair value is non blank.
Figure imgf000031_0003
Figure imgf000032_0001
Parameters
Figure imgf000032_0002
1 -NY/1922975.1 Bot1 OX Engine
Background The BotlOX provides liquidity to the LEH market by partially filling orders that constrain the DAR market. The filled orders are contingent of filling an equivalent (or worse) order in the DAR market.
FIGURE 23 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
FIGURE 24 illustrates a bot responsible for executing partial arbitrage orders that keep the LEH non-deliverable markets in line with the DAR deliverable market.
Processing Flow
FIGURE 25 illustrates a process flow for the bot illustrated in FIGURE 24.
Parameters and Variables
Parameters
Figure imgf000033_0001
1-NY/1922975.1
Figure imgf000034_0001
Internal cache <In certain embodiments, an internal cache is not required >
External cache DarBidPrice = best bid from DAR DarBidSize = size of best bid from DAR DarAskPrice = best ask from DAR DarAskSize = size of best ask from DAR LehBidPrice = best bid from LEH LehBidSize = size of best bid from LEH LehAskPrice = best ask from LEH LehAskSize = size of best ask from LEH
Order book cache DarLimitBid = active DAR limit bid DarLimitAsk = active DAR limit ask DarBuy = active DAR buy order (used for arb's) DarSell = active DAR sell order (used for arb's) LehSell = active LEH sell order LehBuy = active LEH buy order
l-NY/1922975.1 StaleCancels = stale cancelled orders
Stateless local variables DarBidAdjPrice = best bid price from DAR excluding BotlOX DAR bid DarBidAdjSize = best bid size from DAR excluding BotlOX DAR bid DarAskAdjPrice = best ask price from DAR excluding BotlOX DAR ask DarAskAdjSize = best ask size from DAR excluding BotlOX DAR ask TargetBidSize = target bid size for DAR order to provide liquidity to LEH bid TargetBidPrice = target bid price for DAR order to provide liquidity to LEH bid TargetAskSize = target ask size for DAR order to provide liquidity to LEH ask TargetAskPrice = target ask price for DAR order to provide liquidity to LEH ask
Functions and Pseudocode
Arbitrager) NoLehBid = LehBidSize <= 0.0 NoLehAsk = LehAskSize <= 0.0 DarBidArb = DarBidPrice ≥ LehAskPrice + AskArbDelta DarAskArb = DarAskPrice ≤ LehBidPrice - BidArbDelta ifUNoLehAsk && DarBidArb) ExecuteArb("DARSeIl") ifUNoLehBid && DarAskArb) ExecuteArb("DARBuy") if(IDarBidArb || !DarAskArb){ if( INoLehBid) CheckDARBidO if(!NoLehAsk) CheckDARAsk() }
ProcessNewDARPriceO // Process New Bid UpdateMarketDataCache(DarBidPrice, DarBidSize) ; // Update adjust price values If (DarLimitBid = NOLL || DarBidPrice > DarLimitBid.Price){ DarBidAdjPrice = DarBidPrice; DarBidAdjSize = DarBidSize; } else if (DarBidPrice = DarLimitBid.Price){ if(DarLimitBid.Size = DarBidSize) DarBidAdjPrice = NULL else { DarBidAdjPrice = DarBidPrice; DarBidAdjSize = DarBidSize- DarLimitBid.Size; } } else DarBidAdjPrice = NULL // Check for orders If (DarBidPrice ≥ LehAskPrice + Math.Max(AskArbDelta, AskRollArbDelta+RollAskPrice) ExecuteArb("DARSeIl") Else CheckDARBidO; // Process New Ask UpdateMarketDataCache(DarAskPrice, DarAskSize) ; // Update adjust price values If (DarLimitAsk = NULL || DarAskPrice < DarLimitAsk.Price){ DarAskAdjPrice = DarAskPrice; DarAskAdjSize = DarAskSize; } else if (DarAskPrice = DarLimitAsk.Price){ if(DarLimitAsk.Size = DarAskSize) DarAskAdjPrice = NULL else { DarAskAdjPrice = DarAskPrice; DarAskAdjSize = DarAskSize - DarLimitAsk.Size;
1-NY/1922975.1 } } else DarAskAdjPrice = NULL // Check for orders If (DarAskPrice ≤ LehBidPrice-Math.Max(BidArbDelta, BidRollArbDelta-RollBidPrice) ExecuteArb("DARBuy") Else CheckDARAsk() ;
ProcessNewLEHPriceO // New Bid UpdateMarketDataCache(LehBidPrice, LehBidSize) ; // Update target bid size: TargetOrderSize = Math.min(Parmeter.MaxBidSize, Math.floor(LehBidSize * Parmeter.BidLiqFrac) ) ; If (DarAskPrice ≤ LehBidPrice-Math.Max(BidArbDelta, BidRollArbDelta-RollBidPrice) ExecuteArb("DARBuy") Else CheckDARBidO ; // New Ask UpdateMarketDataCache(LehAskPrice, LehASKSize) ; // Update target ask size: TargetOrderSize = Math.min(Parmeter.MaxAskSize, Math,floor(LehAεkSize * Parmeter.AskLigFrac) ) If (DarBidPrice ≥ LehAskPrice + Math.Max(AskArbDelta, AskRollArbDelta+RollAskPrice) ExecuteArb("DARSeIl") Else CheckDARAskO;
ExecuteArb(type) // check for arb on DAR Ask, LEH Bid if(type="DARBuy") { arbSize = min(DarAskSize, LehBidSize, parameter.MaxBidSize) ; If(DarLimitBid!=NULL){ if (DarLimitBid.Price ≥ DarAskPrice) arbSize = arbSize - DarLimitBid.Size; else cancelOrder(DarLimitBid) ; } arbRollSize = min(RollBidSize, arbSize); // check for roll arb if(arbRollSize>0 && DarAskPrice ≤ LehBidPrice-BidRollArbDelta-RollBidPrice){ submitOrder(xLEH', 1RoIlToCaSh', ΛSELL', RollBidPrice - parameter.SellRollImprove, arbRollSize) } // execute remaining arb If(arbSize>0) { submitOrder ("DAR', "2Day# , ""BUY' , DarAskPrice + parameter.BuyDarImprove, arbSize) ; submitOrder ("LEH', "2Day' , "SELL', LehBidPrice - parameter.SellLehlmprove, arbSize) ; }
// check for arb on DAR Ask, LEH Bid if(type="DARSell") { arbSize = min(DarBidSize, LehAskSize, parameter.MaxAskSize) If(DarLimitAsk!=NULL) { if (DarLimitAsk.Price ≤ DarBidPrice) arbSize = arbSize - DarLimitAsk.Size else cancelOrder(DarLimitAsk) } arbRollSize = min(RollAskize, arbSize);
1 -NY/1922975.1 // check for roll arb if (arbRollSize>0 && DarBidPrice ≥ LehAskPrice + AskRollArbDelta+RollAskPrice) { submitOrder ( x LEH ' , 'RollToCash' , "1 SELL' , RollAskPrice _ parameter . BuyRollImprove, arbRollSize) } // execute remaining arb If(arbSize>0) { submitOrder ('DAR', "2Day' , "SELL', DarBidPrice - parameter.SellDarlmprove, arbSize) submitOrder (""LEH', "2Day', 'BUY', LehAskPrice + parameter.BuyLehlmprove, arbSize) }
CheckDARBidf) // Update target bid price: if (DarBidAdjPrice = NULL) TargetBidPrice = LehBidPrice else TargetBidPrice = Math.min(LehBidPrice, DarBidAdjPrice+parameter.MaxBidlmprove) if (DarLimitBid = NULL){ if (LehBidPrice - parameter.BidLimitDelta > DarBidAdjPrice) submitOrder("DAR' , "2Day' , ""BID' , targetPrice, targetSize) } else { if(TargetBidPrice < DarLimitBid.Price | | DarLimitBid.Price < DarBidPrice-parameter.BidMaxGap) cancelOrder(DarLimitBid) else if (TargetBidPrice > DarLimitBid.Price | | TargetOrderSize I= DarLimitBid.Size) cancelReplaceOrder(DarLimitBid, targetPrice, targetSize) }
CheckDARAskO // Update target ask price: if (DarAskAdjPrice = NULL) TargetAskPrice = LehAskPrice else TargetAskPrice = Math.max(LehAskPrice, DarAskAdjPrice - parameter.MaxAsklmprove) If (DarLimitAsk = NULL) { if(LehAskPrice + parameter.BidLimitDelta < DarAskAdjPrice ), submitOrder('DAR', "2Day' , "BID', targetPrice, targetSize) } else { if(TargetAskPrice > DarLimitAsk.Price || DarLimitAsk.Price > DarAskPrice-parameter.AskMaxGap) cancelOrder(DarLimitAsk) ; else if (TargetAskPrice < DarLimitAsk.Price | | TargetOrderSize != DarLimitAsk.Size) cancelReplaceOrder(DarLimitAsk, targetPrice, targetSize) ; }
ProcessDARExecRepfexecRep^ if(execRep.θrderType="LimitBid') { if(Findθrder(execRep, DarLimitBid)){ // Update order book if
Figure imgf000037_0001
DarLimitBid = NULL;
1-NY/1922975.1 else if(execRep.State=~PARTIAL') DarLimitBid.Size = DarLimitBid.Size - execRep.FillSize; else Exception("Invalid state on exec report") } else if((index = FindOrder(exeσRep, StaleCancels)) != NULL){ // Order is a stale cancel - update cancelled order list RemoveOrder(StaleCancels, index) ; } else Warning("Exec report for unknown order") // Submit arb order to LEH if(execRep.State="FILL' || execRep.State=-PARTIAL'){ LehPrice = LehBidPrice - parameter.SellLehlmprove; submitOrder("LEH' , ~2Day', 'SELL', LehPrice, execRep.FillSize, crossover=T) } } else if(execRep.OrderType="LimitAsk') { if(FindOrder(execRep, DarLimitAsk)){ // Update order book if(execRep.State=-FILL' || execRep.State="CANCEL' || execRep.State="REJECT') DarLimitAsk= NULL; else if(execRep.State=~PARTIAL') DarLimitAsk,Size = DarLimitAsk.Size - execRep.FillSize; else Exception("Invalid state on exec report") ; } else if((index = FindOrder(execRep, StaleCancels)) != NULL) { // Order is a stale cancel - update cancelled order list RemoveOrder(StaleCancels, index) ; } else Warning("Exec report for unknown order") // Submit arb order to LEH if(execRep.State=-FILL' || execRep.State="PARTIAL'){ LehPrice = LehAskPrice + parameter.BuyLehlmprove; submitOrder(""LEH' , *2Day' , 'BUY', LehPrice, execRep.FillSize, crossover=T) ; } } else if(execRep.OrderType=~Sell') DarSell=NULL; else if(execRep.OrderType="Buy') DarBuy=NULL; // Update trading restrictions updateTradingRestrictionDataO
Incoming LEH Execution Report 1) Update order book: a) if report is on a Sell order, set LehSell=NULL b) else set LehBuy=NULL
Update Trading Restriction Data 1) Update trade Volume and numTrades of DAR orders over last parameter.TradHistWindow seconds 2) If (trade Volume > MaxTradeVol || numTrades > maxNumTrades) a) tradingHaltTime = curTime + max(parameter.TradingHaltTime, parameter .MinWaitTime) b) else tradingHaltTime = curTime + parameter .MinWaitTime
Submit Order If (DarBuy=NULL && DarSell=NULL && LehBuy=NULL && LehSell=NULL && (tradingHaltTime=NULL || curTime>tradingHaltTime) submitOrderQ
l-NY/1922975.1 10 Bot Specification
Subscriptions and Publications BotlOX subscribe to the following messages
• Price Feed Updates from DAR and LEH • Order Execution Reports from Bot41 • Bot Parameter Control Updates (including pings)
BotlOX publishes the following messages:
• New Order Messages to Bot41 • Control Parameter Settings Report • Botl 00/101 Log Messages
BotlOO BotlOO provides liquidity to LEH orders from the "INCL" price feed. The INCL feed includes all customer orders including on a specific list.
Botl 01 BotlOl provides liquidity to LEH orders from the "EXCL" price feed. The EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
BotlOO (V3)
Background BotlOO/101 has three related but distinct functions
1. Provide liquidity to the LEH market by (partially) submitting limits to the DAR market for LEH orders that constrain the DAR market. 2. Keep the LEH non-deliverable market in line with the DAR market by arbitrging the non-deliverable market with the deliberable market. 3. Keep the LEH deliverable market in line with the DAR deliverable and LEH non- deliverable market by arbitraging roll to cash orders.
Constraining Limit Orders
FIGURE 26 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
Arbitraging PAR and LEH Non-deliverable Markets
FIGURE 27 illustrates a bot responsible for executing partial arbitrage orders that keep the LEH non-deliverable markets in line with the DAR deliverable market.
1-NY/1922975.1 11 Arbitraging LEH Deliverable Market
FIGURE 28 illusrates a BotlOX responsible for executing cash to roll arbitrage orders. In one embodiment, such orders keep both the LEH deliverable and non-deliverablemarkets in line with the DAR deliverable market. A cash to roll arbitrage order can be accompanied by a regular arbitrage order.
Conditions for Arbitraging Roll to Cash Orders
Arb Thresholds ArbBidThresh ArbAskThesh
Bid Offer LEH LehBid LehAsk DAR DarBid DarAsk Roll to Cash RollBid RollAsk
Arb Action on Roll to Cash Bid BotlOO lifts DAR offer Buy DAR DarAsk BotlOO hits LEH bid Sell LEH LehBid BotlOO hits Roll to Cash bid Sell DLV DlvPrice+RollBid Buy LEH DlvPrice
Arb Condition on Roll to Cash Bid LehBid - DlvPrice + DlvPrice +RollBid - DarAsk >= BidArbThresh LehBid + RollBid - BidArbThresh >= DarAsk RollBid >= BldArbThresh-LehBid+DarAsk
Arb Action on Roll to Cash Ask Bot81 hit DAR bid Sell DAR DarBid Bot81 lift LEH ask Buy LEH LehAsk Bot81 lifts Roll to Cash offer Buy DLV DlvPrice+RollAsk Sell LEH DlvPrice
Arb Condition on Roll to Cash Ask DlvPrice-LehAsk+DarBid-DlvPrice -RollAsk >= AskArbThresh DarBid-RollAsk-LehAsk >= BidArbThresh RollAsk <= BidArbThresh+LehAsk-DarBid
Parameters and Variables
Parameters
Figure imgf000040_0001
1-NY/1922975.1 12
Figure imgf000041_0001
Figure imgf000042_0001
Internal cache RecentFills[] = list of exec reports for recent fills RejectPile[] = list of recent rejected orders
External cache DarBidPrice = : best bid from DAR DarBidSize = size of best bid from DAR DarAskPrice = = best ask from DAR DarAskSize = size of best ask from DAR LehBidPrice = : best bid from LEH LehBidSize = size of best bid from LEH LehAskPrice = best ask from LEH LehAskSize = = size of best ask from LEH RollBidPrice = best bid for roll to cash RollBidSize = = size of roll to cash RollAskPrice = best ask for roll to cash RollAskSize = = size of roll to cash
Order book cache DarLimitBid = active DAR limit bid DarLimitAsk = active DAR limit ask DarBuy = active DAR buy order (used for arb's) DarSell = active DAR sell order (used for arb's) LehSell = active LEH sell order LehBuy = active LEH buy order RollBuy = active Roll buy order RollSell = active Roll sell order
Stateless local variables DarBidAdjPrice = best bid price from DAR excluding BotlOX DAR bid DarBidAdjSize = best bid size from DAR excluding BotlOX DAR bid DarAskAdjPrice = best ask price from DAR excluding BotlOX DAR ask DarAskAdjSize = best ask size from DAR excluding BotlOX DAR ask TargetBidSize = target bid size for DAR order to provide liquidity to LEH bid TargetBidPrice = target bid price for DAR order to provide liquidity to LEH bid TargetAskSize = target ask size for DAR order to provide liquidity to LEH ask TargetAskPrice = target ask price for DAR order to provide liquidity to LEH ask
Functions and Pseudocode
1 -NY/1922975.1 14 FIGURE 29 illustrates a process flow for BotlOX.
OnTimerO If (arbTradingOn && (DarBidPrice ≥ LehAskPrice + Math.Max(AskArbDelta, AskRollArbDelta+RollAskPrice))) DarBuyArb() ; else if (arbTradingOn && (DarAskPrice < LehBidPrice - Math.Max(BidArbDelta, BidRollArbDelta-RollBidPrice) ) ) DarSellArbO ; else{ CheckDARBidO CheckDARAsk() }
ProcessNewDARPriceQ // Process New Bid; If its a futures price, then use MinArbSize and // remove our own orders from price,- eventually, this should include // orders from other bots UpdateMarketDataCache(DarBidPrice, DarBidSize, MinArbSize, PriceMarket) ;
// Check whether we are trading on a spot/Dar market TradeDar = TradeMarket='DAR2' | | TradeMarket='DAR3' | | TradeMarket='DAR3'
// Trade if our order appears to have gone traded in DAR If (TradeDar && TradeθnDarPrice=TRUE && DarLimitBid I= NULL && DarAdjPrice = NULL && DarLimitBid.PendingNew=TRUE && (DarBidPrice < DarLimitBid.Price)){ LehPrice = LehBidPrice — parameter.SellLehlmprove; submitOrder(^LEH' , ~2Day' , 'SELL' , LehPrice, DarLimitBid.Size, crossover=T) DarLimitBid = NOLL; } // Update adjust price values for PriceMarket and TradeMarket = DAR If (ITradeDar || PriceMarket!='DAR' || DarLimitBid = NULL || DarBidPrice > DarLimitBid.Price){ DarBidAdjPrice = DarBidPrice; DarBidAdjSize = DarBidSize; } else if (DarBidPrice = DarLimitBid.Price){ if(DarLimitBid.Size = DarBidSize) DarBidAdjPrice = NULL else { DarBidAdjPrice = DarBidPrice; DarBidAdjSize = DarBidSize- DarLimitBid.Size; } } else DarBidAdjPrice = NULL
// Check for orders If (arbTradingOn && (DarBidPrice ≥ LehAskPrice + Math.Max(AskArbDelta, AskRollArbDelta+RollAskPrice)) DarSellArb() ; Else CheckDARBidO; // // Process New Ask UpdateMarketDataCache(DarAskPrice, DarAskSize, MinArbSize, PriceMarket) ; // Trade if our order appears to have gone into the market If(TradeDar && TradeθnDarPrice=TRUE && DarLimitAsk I= NULL && DarAdjPrice = NULL && DarLimitAsk.PendingNew=TRUE && (DarAskPrice < DarLimitAsk.Price) ){ LehPrice = LehAskPrice - parameter.SellLehlmprove;
l-NY/1922975.1 15 US2005/022187
submitOrder ( -LEH' , ~2Day' , "BUY' , LehPrice, DarLimitAsk. Size , crossover=T) DarLimitAsk = NULL; } // Update adjust price values If ((ITradeDar || PriceMarket!='DAR' | | DarLimitAsk = NOLL || DarAskPrice < DarLimitAsk.Price) { DarAskAdjPrice = DarAskPrice; DarAskAdjSize = DarAskSize; } else if (DarAskPrice = DarLimitAsk.Price){ if(DarLimitAsk.Size = DarAskSize) DarAskAdjPrice = NOLL else { DarAskAdjPrice = DarAskPrice; DarAskAdjSize = DarAskSize - DarLimitAsk.Size; } } else DarAskAdjPrice = NOLL // Check for orders If (arbTradingOn && (DarAskPrice ≤ LehBidPrice-Math.Max(BidArbDelta, BidRollArbDelta-RollBidPrice)) DarBuyArb() ; Else CheckDARAskO;
ProcessNewLEHPriceO // New Bid UpdateMarketDataCache(LehBidPrice, LehBidSize) ; // Update target bid size: TargetOrderSize = Math.min(Parmeter.MaxBidSize, Math.floor(LehBidSize * Parmeter.BidLiqFrac)) ; If (DarAskPrice ≤ LehBidPrice-Math.Max(BidArbDelta, BidRollArbDelta-RollBidPrice) DarBuyArbO; l Else CheckDARBidO ; // New Ask UpdateMarketDataCache(LehAskPrice, LehAskSize) ; // Update target ask size: TargetOrderSize = Math.min.(Parmeter.MaxAskSize, Math.floor(LehAskSize * Parmeter.AskLiqFrac)) If (DarBidPrice > LehAskPrice + Math.Max(AskArbDelta, AskRollArbDelta+RollAskPrice) DarSellArbO ; Else CheckDARAskO;
DarBuvArbO // check for arb on DAR Ask, LEH Bid arbsize = min(DarAskSize, LehBidSize, parameter.MaxBidSize) ; If(DarLimitBid!=NOLL){ if (DarLimitBid.Price ≥ DarAskPrice) arbSize = arbSize - DarLimitBid.Size; else cancelOrder(DarLimitBid) ; } arbRollSize = min(RollBidSize, arbSize) ; // check for roll arb if(arbRollSize>0 && DarAskPrice ≤ LehBidPrice-BidRollArbDelta-RollBidPrice){ rollOrder = createOrder(λLEH' , *RollToCash' , 4SELL', RollBidPriσe - parameter.SellRollImprove, arbRollSize) } else rollOrder=NULL // execute remaining arb If(arbSize>0) { darOrder = σreateOrder CDAR', ~2Day', ^BUY', DarAskPrice +
!-NY/1922975.1 16 parameter.BuyDarlmprove, arbSize) ; lehOrder = createOrder ("LEH', ~2Day' , "SELL', LehBidPrice - parameter.SellLehlmprove, arbSize) ; if(rollOrder != NULL) submitOrder(rollOrder, darOrder, lehOrder); else submitorder(darOrder, lehOrder); }
DarSellArbf) // check for arb on DAR Ask, LEH Bid arbSize = min(DarBidSize, LehAskSize, parameter.MaxAskSize) If(DarLimitAsk!=NϋLL){ if (DarLimitAsk.Price < DarBidPrice) arbSize = arbSize - DarLimitAsk.Size else cancelOrder(DarLimitAsk) } arbRollSize = min(RollAεkize, arbSize); // check for roll arb if(arbRollSize>0 && DarBidPrice ≥ LehAskPrice + AskRollArbDelta+RollAskPrice){ rollOrder = createOrder(1LEH' , 4RoIlToCaSh', 1BUY', RollAskPrice + parameter.BuyRollImprove, arbRollSize) } else rollθrder=NULL // execute remaining arb If(arbSize>0) { darOrder = createOrder CDAR', "2Day# , "SELL', DarBidPrice - parameter.SellDarImprove, arbSize) lehOrder = createOrder ("LEH', "2Day# , "BUY', LehAskPrice + parameter.BuyLehlmprove, arbSize) if(rollOrder != NULL) submitOrder(rollOrder, darOrder, lehOrder); else submitOrder(darOrder, lehOrder); }
CheckDARBidO // Update target bid price: if (DarBidAdjPrice = NULL) TargetBidPrice = LehBidPrice else TargetBidPrice = Math.min(LehBidPrice, DarBidAdjPrice+parameter.MaxBidlmprove) if (DarLimitBid = NULL) { if (LehBidPrice - parameter.BidLimitDelta > DarBidAdjPrice) submitOrder("DAR' , "2Day' , "BID', targetPrice, targetSize) } else { if(TargetBidPrice < DarLimitBid.Price || DarLimitBid.Price < DarBidPrice-parameter.BidMaxGap) cancelOrder(DarLimitBid) else if (TargetBidPrice > DarLimitBid.Price | | TargetOrderSize != DarLimitBid.Size) cancelReplaceOrder(DarLimitBid, targetPrice, targetSize) }
CheckDARAskO // Update target ask price: if (DarAskAdjPrice = NOLL) TargetAskPrice = LehAskPrice
1-NY/1922975.1 17 else TargetAskPrice = Math.max(LehAskPrice, DarAskAdjPrice - parameter.MaxAsklmprove) If (DarLimitAsk = NULL){ if(LehAskPrice + parameter.BidLimitDelta < DarAskAdjPrice ), submitOrder("DAR' , "2Day' , "BtD', targetPrice, targetSize) } else { if(TargetAskPrice > DarLimitAsk.Price || DarLimitAsk.Price > DarAskPrice-parameter.AskMaxGap) cancelOrder(DarLimitAsk) ; else if (TargetAskPrice < DarLimitAsk.Price | | TargetOrderSize != DarLimitAsk.Size) cancelReplaceOrder(DarLimitAsk, targetPrice, targetSize) ; }
ProcessDARExecRepfexecRep) if(execRep.OrderTypes"LimitBid' && DarLimitBid != NULL) { // Update order book if(execRep.State=-FILL' | | execRep.State="CANCEL' | | execRep.States"REJECT') DarLimitBid = NULL; else if(execRep.States"PARTIAL') DarLimitBid.Size = DarLimitBid.Size - execRep.FillSize; else Exception("Invalid state on exec report") // Submit arb order to LEH if(execRep.State=-FILL' || execRep.State="PARTIAL'){ // check for roll order rollSize = min(RollAskSize, execRep.FillSize); if(DarLimitBid.Price ≥ LehAskPrice + AskRollArbDelta+RollAskPrice) { rollOrder = createOrder(1LEH' , 1RoIlToCaSh' , 1BUY', RollAskPrice + parameter.BuyRollImprove, rollSize) } else rollOrder=NULL LehPrice = LehBidPrice - parameter.SellLehlmprove; sellOrder = createOrder("LEH' , "2Day' , "SELL', LehPrice, execRep.FillSize, σrossover=T) submitOrder(list(sellOrder, rollOrder)) } if(execRep.0rderType="LimitAsk' && DarLimitAsk != NULL) { // Update order book if(execRep.State="FILL' || execRep.State="CANCEL' || execRep.State="REJECT') DarLimitAsk= NULL; else if(execRep.State="PARTIAL') DarLimitAsk.Size = DarLimitAsk.Size - execRep.FillSize; else Exception("Invalid state on exec report"); // Submit arb order to LEH if(execRep.State="FILL' || execRep.State="PARTIAL'){ // check for roll order rollSize = min(RollBidSize, execRep.FillSize); if(DarLimitAsk.Price < LehBidPrice-BidRollArbDelta-RollBidPrice) { rollOrder = createOrder(1LEH' , 1RoIlToCaSh', 1SELL', RollBidPrice - parameter.SellRollImprove, rollSize) } else rollθrder=NULL LehPrice s LehAskPrice + parameter.BuyLehlmprove; buyOrder = createOrder ("LEH', "2Day' , 1BUY', LehPrice, execRep.FillSize, crossoversT) ; submitOrder(list(buyOrder, rollOrder) ) } // Update order book for market orders
1 -NY/1922975.1 18 if (execRep . OrderType= ~ Sell ' ) DarSell=NULL; if (execRep . θrderType= ~Buy' ) DarBuy=NULL;
ProcessLEHExecRepfexecRep) if (execRep . OrderSide= ~Sell ' && execRep . OrderType= "" 2Day' ) LehS el I=NULL ; if (execRep . θrderSide= ~Buy' && execRep .0rderType= -2Day' ) LehBuy=NULL; if (execRep . θrderSide= "Sell ' && execRep . θrderType= "~RollToCash' ) RoIlSeIl=NULL; if (execRep . OrderSide= ~Buy' && execRep . θrderType= ~ RollToCash' ) RoIlBUy=NULL;
SubmitOrder(orderLisf) darTradeRestriction = DarBuy != NULL | | DarSellI=NULL lehTradeRestriction = (curTime < lastLehIOCFillTime + MinWaitTime) ; dar = orderList.DarOrder if(LehBuyI=NULL || LehSell!=NULL || RoIlSeIl=NULL){ IssueWarning("Trade not submitted: open LEH order"); } else if(lehTradeRestriction) { IssueWarning("Trade not submitted: wait period after LEH fill"); } else if(darTradeRestriction && darI=NULL &&. (dar.type=~BUY' | | dar.type="SELL'))){ IssueWarning("Trade not submitted: wait period after DAR fill"); } else submitOrder(orderList)
Bot Specification
Subscriptions and Publications BotlOX subscribe to the following messages
• Price Feed Updates from DAR and LEH • Order Execution Reports from Bot41 • Bot Parameter Control Updates (including pings)
BotlOX publishes the following messages:
• New Order Messages to Bot41 • Control Parameter Settings Report • Botl 00/101 Log Messages
BotlOO Botl 00 provides liquidity to LEH orders from the 'TNCL" price feed. The INCL feed includes all customer orders including on a specific list.
Botl 01 Botl 01 provides liquidity to LEH orders from the "EXCL" price feed. The EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
1-NY/19Z2975.1 19 Bot110 Engine
Background The BotlOX engine executes simple arbitrage opportunities that exist between an underlying and future currency pair.
Basics
Let Bs, As = spot best bid and ask for the currency pair CCY1/ CCY2 Bf, Af = futures best bid, ask and fair value for the currency pair CCYi/ CCY2 d = number of days between the settlement of the spot contract and the futures contract Δr = differential between interest rates for CCYi and CCY2
Using the interest rate parity relationship, define the arbitrage spot rates as
B3= Bf x exp(-Δr x d / 365) Aa= Af x exp(-Δr x d / 365) FVa= FVf x exp(-Δr x d / 365)
An arbitrage opportunity arises if
Ba> As (figure 30) Aa<Bs (figure 31)
FIGURE 30 illustrates a type 1 arbitrage. In an embodiment, a type 1 arbitrage is defined as when the synthetic futures price exceeds the spot price by the arbitrage threshold ArblMinDelta.
FIGURE 31 illustrates a type 2 arbitrage. In an embodiment, a type type 2 arbitrage is defined as when the synthetic futures price is less than the spot price by the arbitrage threshold Arb2MinDelta.
Trading Lot Size Residual For currency pairs in which the spot and futures are traded with inverted contracts, a trading lot size residual may occur. This will mean that even we execute an arbitrage successfully, we still end up with a residual from the trade. Let
P¥$ = futures price for JPY/USD
The spot contract for USD/JPY has a contract size of 1 million and the futures contract for JPY/USD has a contract size of 12.5 million. A single spot contract at 116.14 ¥ per US$ is equivalent in size to 9.29 futures contracts. Since it is not possible to trade a fraction contract size, a residual balance will remain. Parameters and Variables
Parameter Name Units Type Min Def Max Description
1-NY/1922975.1 20
Figure imgf000049_0002
Fixed Parameters o
Figure imgf000049_0001
Internal Cache OpenArb = logical value that indicates whether the bot is in the middle of processing an arbitrage order LastArbTime = last time an arbitrage order was initiated FutPos = unpaired position in futures for closed arb's SpotPos = unpaired position in spot for closed arb's PairedPos = paired positions for closed arb's
External Cache FutAskPx = synthetic best ask FutAskSz = synthetic size at the best ask price FutBidPx = synthetic best bid FutBidSz = synthetic size at the best bid SpotAskPx = best ask SpotAskSz = size at the best ask price SpotBidPx = best bid SpotBidSz = size at the best bid
OrderBook FutOrders = list of open orders in the futures market SpotOrders = list of open orders in the spot market
AlgorithmandPseudocode Mainprocessingloop // Update synthetic futures prices & process exec reports UpdateSyntheticFuturesPriceO ; ProcessFuturesExecRepO ; ProcessSpotExecRepO ; // Check if a new arbitrage is possible if(FutBidPx - SpotAskPx > ArblMinDelta) ExecuteArblO; Xf(ASkBIdPx - FutAskPx > Arb2MinDelta) ExecuteArb2() ; // Check for time outs, remove closed orders, update position info CheckForTimeOuts() ; UpdateOpenOrderList() ; SyntheticFuturesConversionFunctions // futConvFactor = exp(-IRDelta* FutDaysDelta/365) ; RawToSyntheticPrice(price, futlnfo) { if(futlnfo.InvertedPrice) synthetic = futlnfo.futConvFactor / price? else synthetic = futlnfo.futConvFactor * price; return synthetic; }
RawToSyntheticSize(size, price, futlnfo) { if(futlnfo.InvertedPrice) syntheticSize = size * futlnfo.ContractSize / price; else syntheticSize = size * futlnfo.ContractSize; return syntheticSize; }
SyntheticToRawPrice(synthetic, futlnfo) { if(futlnfo.InvertedPrice) price = futlnfo.futConvFactor * synthetic- return price }
1 -NY/1922975.1 22 SyntheticToRawSize (syntheticSize, price, futlnfo) { if(futlnfo.InvertedPrice) size = syntheticSize * price / futlnfo.ContractSize; else size = syntheticSize / futlnfo.ContractSize; return syntheticSize; }
UpdateSvntheticFuturesPricefraw)
FutAskPx = RawToSyntheticPrice(raw.AskPrice, futlnfo); FutBidPx = RawToSyntheticPrice(raw.BidPrice, futlnfo); FutAskSz = RawToSyntheticSize(raw.AskSize, FutAskPx, futlnfo); FutBidSz = RawToSyntheticSize(raw.BidSize, FutBidPx, futlnfo); Execute Arb 10 // round the size down to the nearest 1000000 arbSize = Math.Min(FutBidSz, SpotAskSz, MaxArbSize) ; arbSize = Math.Floor(arbSize/1000000)*1000000;
// check if we can do the arb if(arbSize < MinArbSize) { warning("Arbl possible but not executed: size too small") } else if(ArbOpen){ warning("Arbl possible but not executed: middle of an open arb") } else if(timeDateO - LastArbTime > MinWaitTime){ warning("Arbl possible but not executed: minimum wait time after last arbitrage has not passed") } else { futSz = SyntheticToRawSize(arbSize, FutBidPx, futlnfo) // Submit the futures order first if(arblSequence='FutFirst') { futPx = SyntheticToRawPrice(FutBidPx - FutFirstlmprove, futlnfo) CurFutOrder = CreateOrder(FutMarket, "Bid', FutFirstOrderType, futPx, fUtSz) ; CurSpotOrder = CreateOrder(SpotMarket, "Ask', SpotLastOrderType, SpotAskPx + SpotLastlmprove, arbSize) ; submitOrder(CurFutOrder) ; openArb = TRUE; // Submit the spot order first } else if(arblSequence='SpotFirst1 ){ futPx = SyntheticToRawPrice(FutBidPx - FutLastlmprove, futlnfo); CurFutOrder = CreateOrder(FutMarket, 'Bid', FutLastOrderType, futPx, futSz) ; CurSpotOrder = CreateOrder(SpotMarket, ""Ask' , SpotFirstOrderType, SpotAskPx + SpotFirstlmprove, arbSize) ; submitOrder(CurSpotOrder) ; openArb = TRUE; // Submit both orders simultaneously } else { futPx = SyntheticToRawPrice(FutBidPx - FutLastlmprove, futlnfo); CurFutOrder = CreateOrder(FutMarket, "Bid', FutSimulOrderType, futPx, futSz) ; CurSpotOrder = CreateOrder(SpotMarket, "Ask', SpotSimulOrderType, SpotAskPx + SpotSimulIitiprove, arbSize) ; submitOrder(list(CurFutOrder, CurSpotOrder)) ; } lastArbTime = timeDateO; AddToList(CurFutOrder, FutOrderList) AddToList(CurSpotOrder, SpotOrderList) }
l-NY/1922975.1 23 ExecuteArb2Q // round the size down to the nearest 1000000 arbSize = Math.Min(FutAskSz, SpotBidSz, MaxArbSize) ; arbSize = Math.Floor(arbSize/1000000)*1000000;
// check if we can do the arb if(arbSize < 1000000){ warning("Arbl possible but not executed: size too small") } else if(ArbOpen){ warning("Arbl possible but not executed: middle of an open arb") } else if(timeDateO - LastArbTime > MinWaitTime){ warning("Arbl possible but not executed: minimum wait time after last arbitrage has not passed") } else { futSz = SyntheticToRawSize(arbSize/ FutAskPx, futlnfo) // Submit the futures order first if(arblSequence='FutFirst') { futPx = SyntheticToRawPrice(FutAskPx + FutFirstlmprove, futlnfo) CurFutOrder = CreateOrder(FutMarket, ""Ask', PutFirstOrderType, futPx, futSz) ; CurSpotOrder = CreateOrder(SpotMarket, "Bid' , SpotLastOrderType, SpotBidPx - SpotLastlmprove, arbSize) ; submitOrder(CurFutOrder) ; openArb = TRUE; // Submit the spot order first } else if(arblSequence='SpotFirst') { futPx = SyntheticToRawPrice(FutAskPx + FutLastlmprove, futlnfo); CurFutOrder = CreateOrder(FutMarket, "Ask', FutLastOrderType, futPx, futSz) ; CurSpotOrder = CreateOrder(SpotMarket, "Bid', SpotFirstOrderType, SpotBidPx - SpotFirstlmprove, arbSize) ; submitOrder(CurSpotOrder) ; openArb = TRUE; // Submit both orders simultaneously } else { futPx = SyntheticToRawPrice(FutAskPx + FutLastlmprove, futlnfo); CurFutOrder = CreateOrder(FutMarket, "Ask', FutSimulOrderType, futPx, futSz) ; CurSpotOrder = CreateOrder(SpotMarket, "Bid', SpotSimulOrderType, SpotBidPx - SpotSimulImprove, arbSize) ; submitOrder(list(CurFutOrder, CurSpotOrder)) ; } lastArbTime = timeDateO; AddToList(CurFutOrder, FutOrderList) AddToList(CurSpotOrder, SpotOrderList) }
ProcessFutExecReporUexecRep) index = matchOrder(FutOrderList, execRep) ; if(index==NULL) error("Exec report for unknown order");
// update the order info if(execRep.State="REJECT') { error("Order rejected") FutOrderList[index] .isOpen = FALSE; } else if (execRep.State="CANCEL'){ FutOrderList[index] .isOpen = FALSE; } else if (execRep.State="PARTIAL' || execRep.State=■FILL"){ size = FutOrderList[index] .FillSize avgpx = FutOrderList[index] .AvgPriσe
1-NY/19229751 24
Figure imgf000053_0001
UpdateOpenOrderListffutPos, spotPos, pairedPos) 1 -NY/1922975.1 25 US2005/022187
changed = FAIiSE; for (index=0 ; index<FutOrderList . Length; index++) { future = FutOrderList[index] ; spot = SpotOrderList[index] ;
// update the positions if an Arb has closed out if(!future.isOpen && 1spot.isOpen){ changed = TRUE; if(future.FillSize > 0){ futPx = RawToSyntheticPrice(future.AvgPriσe, futlnfo) ; futSz = RawToSyntheticSize(future.FillSize, futPx, futlnfo); } else futSz = 0; // update the future position if traded more futures if(futSz > spot.FillSize) { if(future.Size='Bid') sign=l; else sign=-l; size = sign * (futSz - spot.FillSize) ; origSize = futPos.Size; futPos.Size = origSize + size; if(futPos.Size == 0) futPos.AvgPrice = NULL else futPos.AvgPrice = (futPos.AvgPrice*origSize + size*futPx)/futPos.Size; // update the spot position if traded more spot } else if(futSz < spot.FillSize){ if(spot.Size='Bid') sign=l; else sign=-l; ' size = sign * (spot.FillSize - futSz) ; origSize = spotPos.Size; spotPos.Size = origSize + size; if(spotPos.Size == 0) spotPos.AvgPrice = NULL else spotPos.AvgPrice = (spotPos.AvgPrice*origSize + size*spot.AvgPrice)/ spotPos.Size; } // update the P&L on paired trades pairedSize = Min(futSz, spot.FillSize) if(pairedSize>0) { if(spot.Size='Bid') sign=l; else sign=-l; pi = sign*pairedSize*(spot.AvgPrice-futPx) pairedPos.PL = pairedPos.PL + pi; pairedPos.Size = pairedPos.Size + pairedSize; } // remove filled orders removeFromList(SpotOrderList, index) ; removeFromList(FutOrderList, index) ; } // If any arbs have been closed out, publish the P&L changes if (changed) : log(spotPos) log(futPos) log(pairedPos) } CheckForTimeOutsO
for(index=0; index<FutOrderList.Length; index++) { // futures orders future = FutOrderList[index] ; // check for limit order to be cancelled; if cancelled, reset order
I-NY/1922975.1 26 // time for time outs if((future.OrderType = "Limit" || future.OrderType = "LimitMarket") && future.Status="Active" && (timeDateO-future.OrderTime >= FutLimitTime) ){ future.OrderTime = timeDateO; CancelOrder(future) ; // check for order time out } else if(timeDateO -future.OrderTime >= FutTimeOut) { error("Order timed out") future.isOpen = FALSE; } //spot orders spot = SpotOrderList [index] ; j // check for limit order to be cancelled; if cancelled, reset order // time for time outs if((spot.OrderType = "Limit" || spot.OrderType = "LlmitMarket") && spot.Status="Active" ££ (timeDate()-spot.OrderTime >= SpotLimitTime)) CancelOrder(spot) ; // check for order time out } else if(timeDate() -spot.OrderTime >= SpotTimeOut) { error("Order timed out") spot . isOpen = FALSE; } }
Bot120 Engine
Background
Botl20 uses an algorithm to sell a fixed inventory over a time period at a uniform rate. The algorithm optimizes the price under the following assumptions:
• The only type of crossing orders are market orders with no price restriction. • We only send out and update orders at regular time intervals separated by Δ seconds. • The probability that a crossing order occurs in a time interval Δ is αt. • The size of a crossing order has an exponential distribution with mean βt. • The probability that our limit order is filled or partially filled depends on αt, βt and the total size of orders in front of our limit order υt. • We only know about market orders that trade against our orders. • We set a limit on the maximum order size at any time.
Botl20 is characterized by "trading sessions" where a trading session is started when trading is turned off and ended when inventory is used up or trading is turned off. Once a sessions is ended, it cannot be restarted.
Since we only know about market orders that trade against our own orders, the algorithm only learns when we are actually trading. To avoid problems with burn-in, we optionally permit the Bot to retain infoπnation about old orders.
Algorithm
Processing Flow
FIGURE 32 illustrates the processing Flow for Botl20.
1-NY/1922975.1 27 Parameters
Figure imgf000056_0001
Bot20 Engine
Background Bot20 provides liquidity to the LEH market. It maintains four stacks, two on the bid side and two and the ask side. Each stack has a target distribution that is constantly evolving according to shifts in fair value.
FIGURE 33 illstrates the notional stacks of Bot20. In an emobidment, Bot20 maintains four notional stacks, each with a target distribution.
Protecting Against Pickoffs
FIGURE 34 illustrates an embodiment for protecting against pick-offs on bids in the stack
FIGURE 35 illustrates an embodiment for protecting against pick-offs on asks in the stack.
1-NY/1922975.1 28 Adjusting for PAR Roll Differential Let
DarDate = DAR settlement LehDate = LEH settlement date
Normally, DarDate=LehDate and no adjustment is needed. However, if DarDate>LehDate, then fair value must be adjusted as follows:
FairValueAdj = FairValue-RollMid
where RollMid = Midquote for the rolls from LehDate to DarDate.
Correspondingly, if DarDate<LehDate, then
FairValueAdj = FairValue+RollMid
If RollMid is not defined, then set RollMid=0.
Classes
Messages
Subscribes to: • Filtered price messages from Botl 0 • Execution report from Bot41 • Market data messages from LEH (to obtain roll price) • Bot Control messages
Publishes: • New/Cancel Order Messages to Bot41 • Bot Control messages
Bot2X Engine
Background
FIGURE 36 illustrates four notional stacks for Bot2X. In an embodiment, each stack can have a target distribution.
FIGURE 37 illustrates an embodiment for protecting against pick-offs on bids in the stack.
FIGURE 38 illustrates and emobidment for protecting against pick-offs on asks in the stack.
1-NY/1922975.1 29 Algorithm and Processing Flow
Order Gating Order gating is used for markets in which we can only maintain a limited number of actual orders in the stack. In this case, the Bot maintains a virtual stack
Off-All Gating On entry, after receipt of an execution report
• if it's a complete fill, then drop the order from the stack • if it's a partial fill, then update the order size
On exit, for cancel order messages:
• if any active orders are cancelled, then send a clear-all message and make all orders inactive; set numActiveBids (numActiveAsks) to 0 • delete cancelled orders from stack
If there are N>maxInactiveBetterBids (maxInactiveBetterBids) inactive orders that better than an active order in the stack, then
• then send a clear-all message and set numActiveBids (numActiveAsks) to 0
On exit, if the number of active orders numActiveBids (numActiveAsks) is less than orders maxActiveBids (maxActiveAsks), then
• send new order messages for the orders at the top of stack until we have maxActiveBids (maxActiveAsks) that are active.
Selective Cancel Gating
On entry, after receipt of a cancel confirmation:
• if the order is active, then drop the order from the stack. • if the order is "inactive pending", then convert the order to "inactive"
On entry, after receipt of an execution report
• if it's a complete fill, then drop the order from the stack • if it's a partial fill, then update the order size
On exit, for cancel order messages:
• send a cancel order message for active orders • delete order from stack for inactive orders
If the number of active bids (asks) is less than "numActiveBids" ( "numActiveAsks"), then
1 -NY/1922975.1 30 • send a new order message for the order at the top of stack. If there are N inactive orders better than an active order in the stack, then send a cancel order message for the worst N active orders and make these orders inactive pending confirmation
Inputs Filled Order Message Message Subject "LEH.EPX.MLN.DEALS.OUT.FILL.LEHMAN.B0T20.8' Required Fields
Figure imgf000059_0001
Filtered Price Message
Message Subject 11LEH.MERLIN.PRICE.FX.SPOT.<syτnbθl>.NORMB" <symbol> = "EURUSD" or "EURJPY" or "USDJPY" Required Fields
Figure imgf000059_0002
Settlement Date Message Subject "LEH.EFX.MLN.SETTLE.OUT.<symbol>" Required Fields:
Figure imgf000059_0003
1-NY/1922975.1 31
Figure imgf000060_0001
Bot Control Request
Message Subject "LEH.MERLIN.CTRL.BOT20.<symbol>.IN" <symbol> = "ALL" | "EUR/USD" | "EUR/JPY" "USD/JPY" Message Format
Figure imgf000060_0002
Outputs Cancel/New Order Message Message Subject New order messages: " LEH . EFX . MLN . DEALS . IN . LEHMAN . BOT2 o . D " Cancel order messages: » LEH . EFX . MLN . DEALS . IN . LEHMAN . BOT2 o . F " Message Format
Figure imgf000060_0003
l-NY/1922975.1 32
Figure imgf000061_0001
Parameter Settings Report Bot20 publishes its current parameter settings if a Bot Control message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified.
If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting.
Message Subject: parameter refresh messages: "LEH . MERLIN . CTRL . BOT2 O . <coiumn> . OUT"
<column> = "ALL" | "EUR/USD" | "EUR/JPY" | "USD/JPY"
Required Fields
Figure imgf000061_0002
Bot20Info Message
Message Subject "LEH.MERLIN.BOT20.INFO.<<activitytype>>" <<activitytype>> = "NOTRADE" | "TRADE"
Message Format
Figure imgf000061_0003
1-NY/1922975.1 33
Figure imgf000062_0001
Classes
Bot20Cache
Figure imgf000062_0002
Bot20Stack
Figure imgf000062_0003
Engines
Bot20Manager
Subscribes to: • Filtered price message • Execution report • Bot Control request
Publishes: • New Order Messages • Cancel Order Messages • Parameter settings report
1 -NY/1922975.1 34 Bot22 Engine Background Bot22 maintains orders at the top of the market according to a fair-value and threshold.
Figure imgf000063_0001
TargetBid = FairValue - Radius*bidRadiusMult - bidDelta TargetAsk = FairValue + Radius*askRadiusMult + askDelta Internal cache None External cache FairValue = Fair value from pricing Bot Radius = Radius from pricing Bot Order book cache Bid = current bid Ask = current ask Stateless local variables TargetBid = target bid price TargetAsk = target ask price
Functions and Pseudocode ProcessNewPriceQ // If target market is futures, then need to translate PairValue // and Radius into units of the futures market // // Calculate new target prices TargetBid = roundToDigits(FairValue - Radius*bidRadiusMult - bidDelta/10Λdigits, digits); TargetAsk = roundToDigits(FairValue + Radius*askRadiusMult + askDelta/10Adigits, digits); if(TargetBid > FairValue) TargetBid TargetBid - 10A-digits; if(TargetAsk < FairValue) TargetAsk TargetBid + 10Λ-digits,• if(TargetBid==TargetAsk) TargetAsk TargetAsk+10A-digits
// Submit a new bid if the target bid price has changed If (Bid==NULL Il Bid.Price!=TargetBid) { if(BidI=NULL) CancelOrder(Bid) ;
l-NY/1922975.1 35
Figure imgf000064_0001
Bot22 Engine Background Bot22 maintains orders at the top of the market according to a fair-value and threshold. FIGURE 39 illustrates the operation of one embodiment of Bot22.
Figure imgf000064_0002
l-NY/1922975.1 36
Figure imgf000065_0001
TargetBid = FairValue - Radius*bidRadiusMult - bidDelta TargetAsk = FairValue + Radius*askRadiusMult + askDelta Internal cache None External cache FairValue = Fair value from pricing Bot Radius = Radius from pricing Bot Order book cache Bid = current bid Ask = current ask Stateless local variables TargetBid = bid price threshold LastTargetBid = previous bid price threshold TargetAsk = ask price threshold LastTargetAsk = previous ask price threshold FunctionsandPseudocode ProcessNewPriceO // If target market is futures, then need to translate FairValue // and Radius into units of the futures market // // Calculate new target prices TargetBid = roundToDigits(FairValue - Radius*bidRadiusMult - bidDelta/l0Adigits, digits); TargetAsk = roundToDigits(FairValue + Radius*askRadiusMult + askDelta/10Λdigits, digits) ; if(TargetBid > FairValue) TargetBid = TargetBid - 10Λ-digits; if(TargetAsk < FairValue) TargetAsk = TargetBid + 10A-digits; if(TargetBid = TargetAsk) TargetAsk = TargetAsk + 10Λ-digits
// Submit a new bid if the target bid price has changed If (Bid==NULL | | LastTargetBid!=TargetBid) { if(BidI=NULL) Cancelθrder(Bid) ; Px = TargetBid - generateExpRV(BidPriceRange, BidPriceScale) ; Sz = BidMinSise + generateΞxpRV(BidMaxSize-BidMinSize, BidPriceScale) ; Bid = createOrder ("BID', Px, Sz); submitOrder(Bid) ; } // Submit a new ask if the target ask price has changed If (Ask==NOLL I l LastTargetAsk!=TargetAsk) { if(Ask!=NULL) CancelOrder(Ask) ; Px = TargetAsk + generateExpRV(AskPriceRange, AskPriceScale) ; Sz = AskMinSize + generateExpRV(AskMaxSize-AskMinSize, AskPriceScale) ; Ask = createOrder ("ASK', Px, Sz); submitOrder(Ask) ; }
GenerateExpRVCn, scaled // sizeTarget has values from l:n and we want to sample from // 0: (n-1) if(n==0) return(O); rate = scale/(n+1) ;
1-NY/1922975.1 37 df = sizeTarget (n+1, rate) rv = sampleValue (df ) ; return (rv-1) ; ProcessExecReportO
if (execRep . State= "FILL' | | execRep . State= -CANCEL' | | execRep . State= -REJECT' ) {
if (execRep . Order ID = Bid . OrderID) Bid = NULL ; else if (execRep . OrderID = Ask. OrderID) Ask = NULL;
if (execRep . State= -REJECT' ) error ( "Order rejected" )
Bot22 Engine
Background The Bot22 is an electronic market making engine for the DAR market. It maintains one or more bids and offers on each side of the market. If the market price moves away from one side of Bot22 orders, then Bot22 cancels the order furthest from the market and submits a new order close to the market. The threshold for Bot22 can be taken from Bot20, or can be set independently.
FIGURE 40 illustrates thresholds and parameters as described in connection with Bot22.
Parameters and Variables
Parameters
Figure imgf000066_0001
l-NY/1922975.1 38
Figure imgf000067_0001
Internal cache RecentFills[] = list of exec reports for recent fills RejectPile[] = list of recent rejected orders 1 -NY/1922975.1 39 External cache DarBidPrice = best bid from DAR DarAskPrice = best ask from DAR FairValue = fair value as predicted by botlO Radius = radius as predicted by botlO BidDelta20 = bid delta from bot20 (equal to bot20 parameters BidDelta+BidNewDeltaO) BidRadiusMult20 = bid radius multiplier from botlO (equal to bot20 parameters BidRadiusMult*BidNewRadiusMult) AskDelta20 = Ask delta from bot20 (equal to bot20 parameters AskDelta+AskNewDeltaO) AskRadiusMult20 = Ask radius multiplier from botlO (equal to bot20 parameters AskRadiusMult*AskNewRadiusMult)
Order book cache Bids = active bids sorted from best price to worst Asks = active asks sorted from best price to worst
Stateless local variables BidThresh[] = vector of bid price thresholds AskThresh[] = vector of ask price thresholds BidMinGap = minimum gap between best market bid and the best Bot22 bid BidMaxGap = maximum gap between best market bid and the worst Bot22 bid AskMinGap = minimum gap between best market ask and the best Bot22 ask AskMaxGap = maximum gap between best market ask and the worst Bot22 ask
Functions and Pseudocode
FIGURE 41 illustrates the flow of an embodiment of Bot22.
The following Bot22 specific functions are defined:
CheckNewBidO = check to see if a new bid should be submitted CheckNewAsk() = check to see if a new ask should be submitted ProcessNewDARPrice() = process an incoming new price from DAR ProcessDARExecRepO = process an incoming exec report from DAR CheckForTradingHaltO = update information used to impose a trading halt GeneratePriceO = generate the price of a new order GenerateSize() = generate the size of a new order SampleDiscreteO = sample from a discrete probability distribution
See below for details on the Bot22 specific functions
These functions make reference to following generic functions (specs not provided):
BottomOfBookQ = last order in the book NumOrder() = number of orders in book TradeVolume()= volume of trades in an order book SubmitOrderQ = submit an order CancelOrderO = cancel specified order GenerateUniformRVO = generate a uniform (0,1) random variate
1-NY/1922975.1 40 ProcessNewDARPriceQ //Process New Bid UpdateMarketDataCache(DarBidPrice) ; If (Bids[0] .Price < DarBidPrice - Parameter.BidMinGap) CancelOrder(BottomOfBook(Bids)) If (BottomOfBook(Bids) .Price < DarBidPrice - Parameter.BidMaxGap) CancelOrder(BottomOfBook(Bids) )
//Process New Ask UpdateMarketDataCache(DarAskPrice) ; If (Asks[0] .Price > DarAskPrice + Parameter.AskMinGap) CancelOrder(BottomOfBook(Asks) ) ; If (BottomOfBook(Asks) .Price > DarAskPrice + parameter.BidMaxGap) CancelOrder(BottomOfBook(Asks) ) ;
//Process New Fair Value or Radius UpdateMarketDataCache() //Recompute bid thresholds If(BidPegToBot20) { BidRadiusO = Radius * BidRadiusMultBot20 BidDeltaO = BidDeltaBot20 } else { BidRadiusO = Radius * BidRadiusMult BidDeltaO = BidDelta } BidThresh[0] = FairValue-BidRadiusO-BidDeltaO; if(BidNumOrders>l) { for(i=l; i<BidNumOrders; i++) { BidThresh[i] = BidThresh[i-l] - BidNextDelta; } } //Recompute ask thresholds If(AskPegToBot20) { AskRadiusO = Radius * AskRadiusMultBot20 AskDeltaO = AskDeltaBot20 } else { AskRadiusO = Radius * AskRadiusMult AskDeltaO = AskDelta } AskThresh[0] = FairValue+AskRadiusO+AskDeltaO; if(AskNumOrders>l){ for(i=l; i<AskNumOrders; i++){ AskThresh[i] = AskThresh[i-l] + AskNextDelta; } } //Check for new orders CheckNewBidO ; CheckNewAskO ;
ProcessDARExecRepQ //Process Fill <<Update order book Bids[] or Asks[]>> AppendToList(RecentFills[] , execRep) ; CheckForTradingHalt() ; If(orderType(Fill) = "BID") CheckNewBidO ; Else CheckNewAskO;
//Process Cancel <<Update order book Bids[] or Asks[]>>
1-NY/1922975.1 41 If(orderType(Fill) = "BID") CheckNewBidO; Else CheckNewAskO ;
//Process Reject <<Update order book Bids[] or Asks[]>> AppendToList(RejectPile[] , execRep) ; CheckForTradingHaltO ;
CheckNewBidO While (NumOrders(Bids) < parameter.BidNumOrders) { i=0; // find the smallest index i such that the bid price is outside of // the threshold range while(Bids[i] .Price > BidThreshti] -BidRange) { i=i+l; } price = BidThreshti] - GeneratePrice(BidRange, BidGeomProb) size = GenerateSize(BidSizeMin, BidSizeMax) SubmitOrder(parameter.BidMarket, "BID", price, size); }
CheckNewAskO While (NumOrders(Asks) < parameter.AskNumOrders){ i=0; // find the smallest index i such that the ask price is outside of // the threshold range while(Asks[i] .Price > AskThresh[i] -AskRange) { i=i+l; } price = AskThresh[i] - GeneratePrice(AskRange, AskGeomProb) size = GenerateSize(AskSizeMin, AskSizeMax) SubmitOrder(parameter.AskMarket, vιASK", price, size); }
CheckForTradingHaltO // Check for Rejected Orders n = RejectPile.length; // Remove old rejects from RejectPile for(i=0; i<n; i++){ if(CurTime() -RejectPile[i] .SendingTime > Parameter.RejectHistWindow) RemovePromList(RejectPile, i) ; } If (n > Parameter.MaxRejectOrders) TurnOffTradingO ; IssueΞxceptionO ; // Check for Volume Triggered Trading Halt If (TradeVolume(ReσentFills) > parameter.MaxTradeVoI || RecentFills.length > maxNumTrades) { tradingHaltTime = CurTime() + parameter.TradingHaltTime; IssueWarning() ; }
GeneratePriceCn,p) If(n = 1 Il p >= 1) return(price=0) else if (p<=0) return(price=n-l) else{ // compute a truncated Geometric probability distribution probs = new double[n] ;
1-NY/192Ω975 1 42 probs [0] = p; sumProb = p; for (i=l ; i<n; i++) { probs [i] = (1-p) *probs [i-1] ; sumProb += probs [i] ; } for (i=0 ; i<n; i++) { probs [i] /= sumProb; } // sample from generated probability distribution price = SampleDiscrete(probs) ; return(price) ;
GenerateSizefsO, si) n = Math. floor (sl-sθ) If (n <=0) return (size=sθ) Else{ // compute probability distribution probs = new double[n] ; for(i=0; i<n; i++) probs[i] = 1/n; // sample from probability distribution size = s0 + SampleDiscrete(probs) ; return(size) ; }
SampleDiscrete(probs) n = probs.length U = GenerateUniformRVO j=0; cumProb=probs[0] ; while(U>cumProb && j<n-l) {
cumProb += probs[i] ; } return(j) ;
Bot Specification
Subscriptions and Publications Bot22 subscribe to the following messages
• Price Feed Updates from DAR • Order Execution Reports from Bot41 • Bot Parameter Control Updates (including pings)
Bot22 publishes the following messages:
• New Order Messages to Bot41 • Control Parameter Settings Report • Bot22 Log Messages
1 -NY/1922975.1 43 Bot3X Engine
Background The Bot3X engine executes arbitrage opportunities that exist between different markets. The initial engine works with two markets: a primary market (DAR) and a hedging market (Stack). The two types of arbitrage opportunities that can occur are depicted in figures 42 and 43 below.
FIGURE 42 illustrates a type 1 arbitrage.
FIGURE 43 illustrates a type 2 arbitrage.
Processing Flow FIGURE 44 illustrates an embodiment of the processing flow for Bot3X. In an embodiment, if there are no open Bot3X orders on the primary or hedge exchange, then Bot3X looks for an arbitrage opportunity.
Arbitrage processing flow: 1) Update cache with new market data and execution reports 2) If an order is still open, then quit. 3) If the current time minus the time of the last order is less than minWaitTime, then quit. 4) If an arbitrage opportunity is available, then a) send an order to DAR b) send an order to LEH The size of each order is the minimum of the top of book for DAR and for the Stack.
Bot Specification
Subscriptions and Publications Bot3X subscribes to the following messages
• Price Feed Updates from DAR and LEH • Order Execution Reports from Bot41 • Bot Parameter Control Updates (including pings)
Bot3X publishes the following messages:
• New Order Messages to Bot41 • Control Parameter Settings Report • Bot3X Activity Messages
Bot30 Bot30 arbitrages DAR against LEH based on the "INCL" price feed from LEH. The INCL feed includes all customer orders including on a specific list.
1 -NY/1922975.1 44 Bot31 arbitrages DAR against LEH based on the "EXCL" price feed from LEH. The EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
l-NY/1922975.1 45 Bot32/33 Engine
Background The Bot32 provides liquidity to the LEH market by partially filling orders that constrain the DAR market. The filled orders are contingent of filling an equivalent (or worse) order in the DAR market.
FIGURE 45 illustrates a bot providing liquidity to LEH whenever it is the constraining market.
Processing Flow
FIGURE 46 illustrates a process flow for the bot illustrated in Figure 45.
Parameters and Variables
Parameters
Figure imgf000074_0001
Internal cache <In certain embodiments, an internal cache is not required>
External cache DarBidPrice = best bid from DAR DarBidSize = size of best bid from DAR DarAskPrice = best ask from DAR DarAskSize = size of best ask from DAR LehBidPrice = best bid from LEH LehBidSize = size of best bid from LEH LehAskPrice = best ask from LEH LehAskSize = size of best ask from LEH
Order book cache DarBid = active DAR limit bid DarAsk = active DAR limit ask LehSell = active LEH sell order LehBuy = active LEH buy order
l-NY/1922975.1 46 Stateless local variables DarBidAdjPrice = best bid price from DAR excluding Bot32-33 DAR bid DarBidAdjSize = best bid size from DAR excluding Bot32-33 DAR bid DarAskAdjPrice = best ask price from DAR excluding Bot32-33 DAR ask DarAskAdjSize = best ask size from DAR excluding Bot32-33 DAR ask TargetBidSize = target bid size for DAR order to provide liquidity to LEH bid TargetBidPrice = target bid price for DAR order to provide liquidity to LEH bid TargetAskSize = target ask size for DAR order to provide liquidity to LEH ask TargetAskPrice = target ask price for DAR order to provide liquidity to LEH ask
Algorithm Pseudocode
Incoming New DAR Price or Size New Bid 5) Update market data cache: DarBidPrice, DarBidSize 6) Update adjust price values a) If (DarBid = NULL || DarBidPrice > DarBid.Price) i) DarBidAdjPrice = DarBidPrice ii) DarBidAdjSize = DarBidSize b) else if (DarBidPrice = DarBid.Price) i) if(DarBid.Size = DarBidSize) DarBidAdjPrice = NULL ii) else {DarBidAdjPrice = DarBidPrice; DarBidAdjSize = DarBidSize} c) else error("Shown Dar Bid price less than price of known order") 7) Check for New/Cancel Bid New Ask 1) Update market data cache: DarAskPrice, DarAskSize 2) Update adjust price values a) If (DarAsk = NULL || DarAskPrice < DarAsk.Price) i) DarAskAdjPrice = DarAskPrice ii) DarAskAdjSize = DarAskSize b) else if (DarAskPrice = DarAsk.Price) i) if(DarBid.Size = DarBidSize) DarBidAdjPrice = NULL ii) else {DarAskAdjPrice = DarAskPrice; DarAskAdjSize = DarAskSize} c) else error("Shown Dar Bid price less than price of known order") 3) Check for New/Cancel Ask
Incoming New LEH Price or Size New Bid 1) Update market data cache: LehBidPrice, LehBidSize 2) Update target bid size: TargetOrderSize = min(Parmeter.MaxBidSize, floor(LehBidSize * Parmeter.BidLiqFrac)) 3) Check for New/Cancel Bid New Ask 1) Update market data cache: LehAskPrice, LehASKSize 2) Update target bid size: TargetOrderSize = min(Parmeter.MaxAskSize, floor(LehAskSize * Parmeter.AskLiqFrac)) 3) Check for New/Cancel Ask
l-NY/1922975.1 47 Check for New/Cancel Order Bid 1) Update target bid price: a) if (DarBidAdjPrice = NULL) TargetBidPrice = LehBidPrice b) else TargetBidPrice = min(LehBidPrice, DarBidAdjPrice+parameter.MaxBidlmprove) 2) If (LehSell = NULL && DarBid = NULL && TargetBidPrice > DarBidAdjPrice), submitOrder(DAR, BID, targetPrice, targetSize) 3) Else if (DarBid I=NULL) a) if(TargetBidPrice < DarBid.Price) cancelOrder(DarBid) b) else if (TargetBidPrice > DarBid.Price || TargetOrderSize != DarBid.Size) cancelReplaceOrder(DarBid, targetPrice, targetSize) Ask 1) Update target ask price: a) if (DarAskAdjPrice = NULL) TargetAskPrice = LehAskPrice b) else TargetAskPrice = max(LehAskPrice, DarAskAdjPrice - parameter .MaxAsklmprove) 2) If (LehBuy = NULL && DarAsk = NULL && TargetAskPrice < DarAskAdjPrice), submitOrder(DAR, BID, targetPrice, targetSize) 3) Else if (DarAsk I=NULL) a) if(TargetAskPrice > DarAsk.Price) cancelOrder(DarAsk) b) else if (TargetAskPrice < DarAsk.Price || TargetOrderSize I= DarAsk.Size) cancelReplaceOrder(DarAsk, targetPrice, targetSize)
Incoming DAR Execution Report Bid 1) Update order book: a) if order was a filled or cancelled, set DarBid = NULL b) else if order was a partial fill, DarBid.Size = DarBid.Size - fillSize 2) if order was fill or partial fill, submitOrder(LEH, SELL, DarBid.Price, fillSize, crossover=T)
Ask 1) Update order book: a) if order was a filled or cancelled, set DarAsk= NULL b) else if order was a partial fill, DarAsk.Size = DarAsk.Size - fillSize 2) if order was fill or partial fill, submitOrder(LEH, BUY, DarAsk.Price, fillSize)
Incoming LEH Execution Report 1) Update order book: a) if report is on a Sell order, set LehSell=NULL b) else set LehBuy=NULL
Bot Specification
Subscriptions and Publications Bot32/33 subscribe to the following messages
• Price Feed Updates from DAR and LEH
1 -NY/1922975.1 48 • Order Execution Reports from Bot41 • Bot Parameter Control Updates (including pings)
Bot32/33 publishes the following messages:
• New Order Messages to Bot41 • Control Parameter Settings Report • Bot32/33 Activity Messages
Bot32 Bot32 provides liquidity to LEH orders from the "INCL" price feed. The INCL feed includes all customer orders including on a specific list.
Bot33 Bot33 provides liquidity to LEH orders from the "EXCL" price feed. The EXCL feed includes all orders except those coming from the Bots and those included in the INCL feed.
Bot40 Engine
Background
FIGURE 47 illustrates an embodiment for the flow of Bot40.
The Bot40 engine serves two purposes:
• manual trading actions (buy, sell, bid, or offer) • manual control of the parameters for the trading bots
The engine inputs market data from the bubble filter, controls from the game pad, and parameter changes from other engines (e.g., grid viewer/editor). The engine outputs parameter change messages to StackBot, Bubble and ArbBot and trades to the Merlin OMS and the Stack.
Specification of Game Pad Controls
Toggles and Switches
Although not shown, those skilled in the art will recgonized how to implement an input device with the following functions.
Button 2: Engine Toggle The engine toggle cycles through the different types of trading engines: Bubble, StackBot, ArbBot and ManualTrader. The selection of the engine toggle determines which parameters the game pad is updating.
1-NY/1922975.1 49 Button 1 : Currency Toggle The currency toggle cycles through the different currencies: EUR/USD, USD/JPY, EUR/JPY, and ALL. Selection of "ALL" causes the parameters to be updated for all currencies.
Button 3: On-Off Switch For the trading Bots, the on-off switch turns on and off trading. For the price filters, the on- off switch turns off arbitrage filter. The specific behavior of the on-off switch depends on the engine toggle setting: see the parameter spreadsheet for details.
Button 0: Auxiliary Switch The auxiliary switch is engine dependent. For Bubble, StackBot and ManualTrader, the switch selects the set of parameters are being set through the throttles. For ArbBot, the switch turns on and off trading to DAR.
Trading Buttons
In an embodiment, buttons can support manual trading actions. These buttons can be solely dedicated to trading and can operate regardless of the engine toggle setting.
The trading buttons only control manual trading.
Cancel buttons apply to the current engine selected by the engine toggle. When the bid/ask cancel button is pressed, an order is cancelled out of the top of the bid and ask stack respectively.
The bid/offer buttons and the buy/sell buttons apply on to manual trading regardless of the setting of the engine toggle. These buttons can be de-activated by the Trading on/off switch. The bid/offer buttons place limit orders and the buy/sell buttons place "Immediate or Cancel" orders. The price and size of the orders is determined by the BOT40 (trading) parameters.
Throttles
The throttles control the settings for the key parameters. The left and right throttle have a continuous action outputting values between -1 and 1 along two dimensions. The auxiliary throttle is an 8-way discrete toggle.
The behavior of the throttles are engine dependent. In general, the right throttle controls the price/radius, the left throttle controls the size and the auxiliary throttle controls a secondary parameter.
Inputs
Gamepad Input Bot40 listens to low-level game pad event messages.
l-NY/1922975.1 50 Message Subject: "LEH.MERLIN.GAMEPAD.<clientid>.<action>" <action> = "IDLE" | "BUTTON.0" | ... | "BUTTON.11"
Figure imgf000079_0001
"LEVER.0"
Figure imgf000079_0002
"LEVER.1" I "POV"
Required Fields: Button Actions
Figure imgf000079_0003
Required Fields: Lever Actions
Figure imgf000079_0004
Required Fields: POV Actions
Figure imgf000079_0005
Bot40 Control Request If a bot control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a bot control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
Message Subject "LEH.MERLIN.CTRL.BOT40.<column>.IN" <column> = "ALL" | "EUR/USD" | "EUR/JPY" "USD/JPY"
Message Format
Figure imgf000079_0006
l-NY/l 922975.1 51 Input from BOT50
Message Subject "LEH.MERLIN.B0T5O.<<symbol>>.VOL.5M" <<symbol>> = "EURUSD" or "EURJPY" or "USDJPY"
Figure imgf000080_0002
Values input from Bot50 are used to map parameters for Bot20:
BidSpeed = min(RelVol, maxBidSpeed) AskSpeed = min(RelVol, maxAsklSpeed)
BOTlO Input
Message Subject "LEH.MERLIN.BOTl0.<<symbol>>.PRICE" <<symbol>> = "EURUSD" or "EURJPY" or "USDJPY"
Required Fields
Figure imgf000080_0003
Outputs
Inbound Bot Control Request If a Bot Control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a Bot Control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
Message Subject "LEH.MERLIN.CTRL.<bot>.<symbol>.IN" <bot> = "BOTlO" I "BOT20" | ... <symbol> = "ALL" | "EUR/USD" I "EUR/JPY"
Figure imgf000080_0001
"USD/JPY"
Message Format
Figure imgf000080_0004
1 -NY/1922975.1 52
Figure imgf000081_0001
Parameter Settings Report The Bot40 publishes its current parameter settings if a bot control message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified.
If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting.
Message Subject: parameter refresh messages: "LEH . MERLIN . CTRL . BOT4 O . < column> . our »
<column> = "ALL" I "EUR/USD" I "EUR/JPY" I "USD/JPY"
Required Fields
Figure imgf000081_0002
Bot40 Activity Message
Message Subject "LEH.MERLIN.BOT40.INFO.<bot>.<symbol>.ACTIVITY.<type>" <type> = "PARAMETER" | "NEWORDER" | "CANCELORDER" <bot> = "BOTlO" I "BOT20" I ... <symbol> = "EUR/USD" | "EUR/JPY" | "USD/JPY" | "ALL"
Figure imgf000081_0003
Classes Bot40 has two types parameters:
1-NY/1922975.1 53 • Bot40 internal parameters: switches for the engine, currency and parameter set. • Manual trading parameters: used to determine the price and size at which trades are submitted.
Internal Parameters The internal parameters are:
• Engine toggle: BOTl 0, BOT20, BOT30, BOT31 , or BOT5X. Note that the engine switch does not distinguish between BOT50 or BOT51. • Currency toggle: "ALL", "EUR/USD", "USD/JPY", "EUR/JPY". • Parameter switch (engine dependent).
Manual Trading Parameters
The price at which an order is submitted is obtained as follows:
1. If the bidPrice/askPrice/buyPrice/sellPrice is not NULL, then that price is used. Otherwise, the "auto-price" is used. 2. The auto-price is determined from the cached fair value and radius a. bidAutoPrice = fairValue - bidRadiusMult*radius b. askAutoPrice = fairValue + askRadiusMult*radius c. buyAutoPrice = fairValue + bidRadiusMult*radius d. askAutoPrice = fairValue - askRadiusMult*radius 3. The bidPrice/askPrice/buyPrice/sellPrice are set to NULL each time the engine toggle is changed to "BOT5X" or the currency toggle is changed. 4. The bidPrice/askPrice are set to NULL if the price throttle button is pressed and the parameter model is "Bid/Ask". 5. The buyPrice/sellPrice are set to NULL if the price throttle button is pressed and the parameter model is "Buy/Sell". 6. The bidPrice/askPrice is updated when the price throttle is activated and the parameter model is "Bid/Ask". If the price is NULL, then it is initialized to the auto-price. 7. The buyPrice/sellPrice is updated when the price throttle is activated and the parameter model is "Buy/Sell". If the price is NULL, then it is initialized to the auto- price.
Engines
Bot40
Subscribes to: • Bubble Price Message • Game Pad Messages • Bot40 Parameter settings request
Publishes: • Control message to other Bots • Parameter settings report for Bot40
1-NY/1922975.1 54 • Bot40 Activity Message -NY/1922975.1 55 Bot41 Engine
Background
FIGURE 48 illustrates a network diagram for Bot41. In an embodiment, Bot41 can act as a gatekeeper between the other bots and orders going to and from the markets.
The Bot41 engine is a centralized order management system for all Bots. A centralized Bot OMS offers several benefits:
1. It reduces the number of message that the bots listen to, and hence, reduces their memory requirements. i 2. Easier to decrease transparency of the bots on the TIB: Bot41 can obscure any information specific to a single bot. 3. Abstracts the order away from the specifics of the market; this way, when we hook up new markets, we don't need to change the individual bots. 4. Maintains a central view of our position. 5. Can prevent Bots from trading with each other by rejecting orders that cross other Bot orders.
Processing Flow
Order States: Pending: new order waiting for acknowledgement CancelOnAck: new order to be canceled upon acknowledgement CancelReplaceOnAck: order to be canceled upon acknowledgement Active: acknowledged order live in market CancelP ending: active order waiting for confirmation of a cancel CancelReplaceP ending: active order waiting for confirmation of a cancel/replace
New orders from Bots 8) Validate order: a) market Active, b) valid type, c) if invalid, rej ect order 9) If order crosses any active orders: a) if (new order has CrossOver=T) or (new order has CrossOver=F and all crossed orders have CrossOver=F), the new order takes precedence over all outstanding orders; i) cancel Active crossed orders ii) submit new order b) else reject order 10) If order crosses any pending orders, a) if (new order has CrossOver=T) or (new order has CrossOver=F and all crossed orders have CrossOver=F) i) change status of pending orders to CancelOnAck ii) submit new order
1 -NY/1922975.1 56 b) else reject order 11) Add order onto the internal stack with status Pending 12) Fill in timeDuration field from parameter if missing a) If
Figure imgf000085_0001
then set timeDuration to value of LimitTimeOut parameter b) Else set timeDuration to value of IOCTimeOut parameter 13) Convert the order to a new order message to send to the market
Cancel orders from Bots 1) Validate order: is order in stack a) if invalid, reject order 2) If order is Active, a) change status to CancelPending b) Convert the order to a cancel message to send to the market 3) Else if order is Pending or CancelReplaceP ending or CancelReplaceOnAck a) change status to CancelOnAck 4) Else issue exception
Cancel Replace order from Bots 1) Validate order: is order from DAR and in stack a) if invalid, reject order b) update price and size 2) If order is derive, a) change status to CancelReplaceP ending b) Convert the order to a new order message to send to the market 3) Else if order is Pending or CancelReplaceP ending, a) change status to CancelReplaceOnAck 4) Else if order is CancelReplaceOnAck, do nothing , 5) Else issue exception
Acknowledgements/Execution reports 1) ExecType=O (new order acknowledged): a) If order is from LEH, is in stack and is Pending, i) If order change status to Active ii) update stack with Order ID from the market iii) set time stamp iv) check buffer for cached exec report; if found, process exec b) Else order is from LEH, is in stack and has status CancelOnAck, S) update stack with Order ID from the market ii) Send a cancel message iii) check buffer for cached exec report; if found, process exec c) Else if order is from DAR, do nothing d) Else if order is in reject pile (not owned by a bot) i) update order with Order ID from the market ii) send cancel message iii) change order status to CancelPending e) Else issue exception 2) ExecType=l (partial fill): a) If order is in stack or reject pile i) update stack with remaining size ii) relay message back to the bot
1-NY/1922975.1 57 iii) if order has status CancelOnAck, send a cancel message and set status to CancelP ending iv) Else if order has status CancelReplaceOnAck, send a new order message and set status as CancelReplaceP ending b) Else cache exec report in buffer 3) ExecType=2 (fill) a) If order is in stack or reject pile i) Relay message back to the bot ii) If status is CancelOnAck or CancelOnAck, send reject to the bot iii) If order is not a roll or if order is a roll and this is the 2nd fill report, remove order from stack b) Else cache exec report in buffer 4) ExecType=4 (cancel) a) If order has status CancelPending or Active i) remove order from stack or reject pile ii) relay message back to the bot b) Else issue an exception 5) ExecType=5 (replace), order is from DAR and order is in stack a) Else if order has status CancelOnAck, send a cancel message and set status to CancelPending b) Else if order has status CancelReplaceOnAck, send a new order message and set status as CancelReplaceP ending c) Else if order has status CancelReplaceP ending, change status to Active d) Else if order has status CancelPending, do nothing e) Else issue an exception 6) ExecType=6 (cancel-ack), a) If order does not have status CancelPending or RejectP ending issue an exception 7) ExecType=8 (reject) and order is in stack a) If order does not have status RejectP ending i) issue exception ii) move order to reject stack iii) relay rejection message back to bot 8) ExecType=A (newPending) and order is in stack a) If order is Pending, change status to Active b) Else if order has status CancelOnAck, send a cancel message c) Else issue exception 9) ExecType=C (replacePending) order is from DAR and order is in stack a) Else if order has status CancelOnAck, send a cancel message and set status to CancelPending b) Else if order has status CancelReplaceOnAck, send a new order message and leave status as CancelReplaceP ending c) Else issue expection 10)ExecType=E (expire) and order is in stack a) remove order from stack b) relay expire message back to bot
Settlement date messages: 1) If the settlement date has changed a) update the settlement dates b) send control message to all bots and currency pairs giving new FutSettDate's
1-NY/1922975.1 5g Control Messages: 1) If the control message has the field "SendAll=T", then send a dump of all parameter values 2) If the control message has the field "SendFutSettDate=<bot>", then send a control message to the specified bot giving the current FutSettDate's 3) If the control message has the field "SendSnapshot=<bot>", then send a snapshot of the order book for the specified bot 4) If the control message has the field "ClearReject=<bot>", then clear out the reject stack for the specified bot. 5) If the control message has the field "ClearCache=<bot>", then clear out the internal cache for the specified bot. 6) If the control message has the field "SendCache=<bot>", then dump out the internal cache for the specified bot. 7) If the control message has a field of the form "<parameter>=<value>" where <parameter> is one of the Bot41 parameters (see section 3.2), then a) update the parameter value. b) Send a outbound control message with the updated parameter value
In the above, if <bot>="All", then Bot41 should send a message to all bots.
On Timer: A timer should be set to perform the following actions at an interval specified by the parameter TimeOutTimer:
1) Check stack for time out based on order status: a) If order status is Pending or CancelOnAck, order times-out if time elapsed exceeds AckTimeOut parameter i) If Action = "Limit", change status to CancelOnAck ii) Move order to reject stack iii) Send a reject (time out) to the bot iv) Issue exception b) If order status is Active, check time out against order duration field. If order times- out, then i) If Action = "IOC", (1) Send a reject (time out) to the bot (2) Issue exception ii) Else if Action = "Limit" or "CancelReplace", (1) Send a cancel message (2) Change status to CancelPending c) If order status is CancelPending or CancelReplaceP ending, order times-out if time elapsed exceeds IOCTimeOut parameter i) Move order to reject stack ii) Send a reject (time out) to the bot iii) Issue exception 2) Check buffer for time out on received reports a) If the time on the report exceeds the AckTimeOut parameter i) Remove report from buffer ii) Issue exception 3) Check reject pile
1-NY/1922975.1 59 a) If time elapsed for a rejected order exceeds RejectExpire, then delete order from reject pile and output to archive file b) Of the reject pile has too many orders i) If it exceeds
Bot41 Specifications
Input/Output Overview
Subscribes to: • New/cancel order messages from the BOTS • Acknowledgements and execution reports from DAR markets • Acknowledgements and execution reports from LEH markets • Settlement date message • Bot control requests to modify a Bot41 parameter
Publishes: • Execution reports to the Bots • New/cancel/cancelReplace orders to the DAR markets • New/cancel orders to the LEH markets • Inbound bot control messages to the Bots: settlement date changes to other bots • Outbound bot control parameter settings report o Dump of the internal cache from a SendCache request o Dump of Bot parameters o Changed values of Bot parameters • Bot41 Warning/Error Messages
Bot41 Parameters
Figure imgf000088_0001
1 -NY/1922975.1 60
Figure imgf000089_0001
The Bot41 parameters can be changed through control message sent to Bot41.
Bot41 Warning and Error Messages When Bot41 issues warning or critical errors, it should publish associated infoπnation to help diagnose the error. For example, if Bot41 can't find an order with the inbound client order ID, it should issue the following warning:
LEH.MERLIN.BOT41.INFO.USD/CHF.WARN, msgBody={ Comment="Cannot find the order for this ack: ExecutionReport [headerData={SendingTime=10:10:10.413.001, TargetCompID=LEHBOT, TargetSubID=USD/CHF, SenderCompID=LEH_MARKET, MsgType=8}, bodyData={ExecID=0219.24806.146292, OrdStatus=0, TimeInForce=l, Side=l, AvgPx=0.0000000000, OrderQty=1000000, ClOrdID=BOT20.4.6031.10.10.10.370, LastShares=0, OrdType=F, SettlmntTyp=0, ExecType=0, OrderID=gY77X7QQX7gggX7Y337, Symbol=USD/CHF, CumQty=0, ExecTransType=3, OrdRejReason=N, FutSettDate=0221, TransactTime=0219- 10:10:10.353.002, LeavesQty=1000000, LaStPx=O.0000000000, Price=l.3688000000}] " }"
If Bot41 can't find an order with the inbound match engine order ID, it should issue the following critical error message:
LEH.MERLIN.BOT41.INFO.USD/CHF.ERR, msgBody={ Comment="Cannot find order for this fill exec report, ΞxecReport:ExecutionReport [headerData={SendingTime=0219-09:52:20.351.002, TargetCompID=LEHBOT, TargetSubID=USD/CHF, SenderCompID=LEH_MARKET, MsgType=8}, bodyData={ExecID=0219.24806.139099, OrdStatus=4, TimeInForce=l, Side=l, AvgPx=0.0000000000, OrderQty=2000000, C10rdID=bMt6NIIIMcAMNtIIwd, LastShares=0, OrdType=F, SettlmntTyp=0, ExecType=4, OrderID=bMt6NIIIMcAMNtIIwd, SymboI=USD/CHF, CumQty=0, ExecTransType=3, OrdRejReason=N, FutSettDate=0221, TransactTime=0219-09:52:20.306.000, LeavesQty=0, LaStPx=O.0000000000, Price=l.3711000000}]" }
If Bot41 has too many rejected orders, it should issue the following critical error message:
LEH.MERLIN.B0T41.INFO.USD/CHF.ERR, msgBody={ Comment="Number of reject orders exceeds critical limit of 50 : Side Symbol ******** ciOrdID ******** Price Size State Market Ask EUR/USD BOT50.1.267.10.19.47.846 0000.0003 30000000 Pending LEHl Ask EUR/USD BOT50.1.259.08.57.25.042 0000.0003 30000000 Pending LEHl Ask EUR/USD BOT50.1.135.17.27.25.382 0000.0003 30000000 CancelOnAck LEHl BID EUR/USD BOT50.1.224.18.00.00.502 0000.0002 10000000 Pending DAR3 Ask EUR/USD BOT50.1.136.17.27.25.383 0000.0002 10000000 CancelOnAck LEHl
}
l-NY/1922975.1 61 Bugs and Feature Requests
Urgent
Bug: Pending orders moved to reject pile are lost Description: Orders that don't receive acks in a timely manner are moved to the reject pile and then are effectively lost. Severity/Priority: This can leave orders hanging and allow the bots to trade against each other. Solution: Check the reject pile when acks, fills and cancels come in. Cancel orders that have receive an ack after having been moved to the reject pile. Time Estimate: Vz day
Bug: No time outs for cancel orders Description: Orders that have state "CancelPending" are not timed out if we never receive a confirmation report. Severity/Priority: This can leave bad orders hanging and eventually lead to a shutdown of the Bots. Solution: Time out CancelPending orders using the IOCTimeOut parameter Time Estimate: Vz day
Immediate Priority
Bug: Wrong units for IOCTimeOut parameters Description: The parameter unit for IOCTimeOut is interpreted in hours but it should be in seconds. Severity/Priority: Can work around by sending in parameter changes via control messages. Solution: Fix the units for IOCTimeOut. Time Estimate: 1 hours
Bug: Improper processing of DAR expired orders Description: When the DAR OMS sends back an expired IOC, this is not properly processed and Bot41 sends out a report with Action="IOC". Severity/Priority: Not a problem for the Bots, but misleading. Solution: Set Action="Cancel". Time Estimate: 2 hours
Bug: Spurious exception when on cancel after fill Description: Issue spurious exception when a cancel is sent after the order is filled but before the fill report comes back. Severity/Priority: Not a problem for performance. Not common, but when it occurs, it wastes time in monitoring & debugging. Solution: Create a new order state "RejectPending" and process cancel ack's and cancel rejects as normal. Time Estimate: Vz day
1 -NY/1922975.1 62 Feature: Limit number of exceptions of a given type Description: When the match engine dies, or has some other massive failure, thousands of exceptions can be generated. This floods the e-mail inbox of those receiving the exception reports. Severity/Priority: Not a problem for performance. It's a significant inconvenience for developers; until this is resolved, we need to turn off e-mailing of exceptions Solution: Give the exceptions a key and limit the number of a given type. Allow Bot to receive control messages to clear exception queue. Time Estimate: 1 day
Feature: Improve cross over behavior of orders Description: New liquidity taking orders that cross other bot orders should cause the existing bot orders to be cancelled (to avoid Bots trading with each other). Liquidity providing orders should be able to cross other liquidity providing orders, but not liquidity taking orders. Priority: Needed to ensure proper behavior for Bot30/31 and Bot70. Solution: A simple solution is to insert additional logic upon receipt of new orders to check the order type for crossed orders in the stack, and to cancel crossed orders. In the case that the new order crosses a pending order, the pending orders are cancel on ack and the new order is rejected. Time Estimate: 1A day for simple solution, 1+ days for full solution.
Feature: Output Order Book Snapshots by Bot Description: Send a snapshot of the current state of the order book for a bot. Priority: Needed for fault tolerance of trading bots (Bot20, Bot50, Bot70) Solution: Listen for "SendSnapshot" control messages and respond with the snapshot. Time Estimate: 1 day for simple solution.
Feature: Fault Tolerance Description: Support a secondary Bot41 and switch over in the event of failure to the primary. Priority: Needed for fault tolerance. Solution: Act as a fully functional shadow bot except that no messages are published. On failover, the secondary bot must determine how many messages were lost, send the lost messages and then carry on forward as the primary bot. Time Estimate: 3+ days.
Future Priority Feature: Listen directly to orders from ME (not OMS) Priority: By listening to the ME, we can receive information quicker. The disadvantage is that the orders are not serialized, so we need to put in logic in Bot41 to handle this. Solution: Create a local cache for fills that arrive before acks. Process the orders in the cache when the ack arrives Time Estimate: 1+ day
1-NY/1922975.1 63 Bot41 Engine: Version 2
Background
FIGURE 49 illustrates a network diagram for Bot41. In an embodiment, Bot41 can act as a gatekeeper between the bots and orders going to and from the markets.
The Bot41 engine is a centralized order management system for all Bots. A centralized Bot OMS offers several benefits:
1. It reduces the number of message that the bots listen to, and hence, reduces their memory requirements. 2. Easier to decrease transparency of the bots on the TIB: Bot41 can obscure any information specific to a single bot. 3. Abstracts the order away from the specifics of the market; this way, when we hook up new markets, we don't need to change the individual bots. 4. Maintains a central view of our position. 5. Can prevent Bots from trading with each other by rejecting orders that cross other Bot orders.
Processing Flow
Order States: Pending: new order waiting for acknowledgement Active: acknowledged order live in market CancelP ending: active order waiting for confirmation of a cancel
New orders from Bots 14) Validate order: a) market Active, b) valid type, c) if invalid, reject order 15) If order crosses any orders: a) if (new order has CrossOver=T) or (new order has CrossOver=F and all crossed orders have CrossOver=F), the new order takes precedence over all outstanding orders; i) cancel crossed orders ii) submit new order b) else reject order 16) Add order onto the internal stack with status Pending 17) Send new order message to the market
Cancel orders from Bots 5) Validate order: is order in stack a) if invalid, reject order 6) If order is Active or Pending, a) Move order to CancelPending stack b) Send cancel order to the market 7) Else issue exception
1 -NY/1922975.1 64 Acknowledgements/Execution reports 11) ExecType=O (new order acknowledged): a) If order is from LEH, is in stack and is Pending, i) If order change status to Active ii) update stack with Order ID from the market iii) set time stamp iv) check buffer for cached exec report; if found, process exec b) Else if order is from DAR, do nothing c) Else issue exception 12)ExecType=l (partial fill): a) If order is in stack i) update stack with remaining size ii) relay message back to the bot b) Else cache exec report in buffer 13)ExecType=2 (fill) a) If order is in stack i) Relay message back to the bot ii) If order is not a roll or if order is a roll and this is the 2nd fill report, remove order from stack b) Else cache exec report in buffer 14)ExecType=4 (cancel) or ExecType=E (expire) a) If order has status CancelP ending or Active i) remove order from stack or cancelPending pile ii) relay message back to the bot b) Else issue an exception 15)ExecType=6 (cancel-ack), a) If order does not have status CancelPending issue an exception 16) ExecType=8 (reject) and order is in stack a) issue exception b) relay rejection message back to bot 17)ExecType=A (newPending) and order is in stack a) If order is Pending, change status to Active and send message to bot b) Else issue exception 18)ExecType=C (expired) order is from DAR and order is in stack a) Issue exception
Settlement date messages: 2) If the settlement date has changed a) update the settlement dates b) send control message to all bots and currency pairs giving new FutSettDate's
Control Messages: 8) If the control message has the field "SendAll=T", then send a dump of all parameter values 9) If the control message has the field "SendFutSettDate=<bot>", then send a control message to the specified bot giving the current FutSettDate's 10) If the control message has the field "SendSnaρshot=<bot>", then send a snapshot of the order book for the specified bot
1-NY/192297S.1 65 11) If the control message has the field "ClearReject=<bot>", then clear out the reject stack for the specified bot. 12) If the control message has the field "ClearCache=<bot>", then clear out the internal cache for the specified bot. 13) If the control message has the field "SendCache=<bot>", then dump out the internal cache for the specified bot. 14) If the control message has a field of the form "<parameter>=<value>" where <parameter> is one of the Bot41 parameters (see section 3.2), then a) update the parameter value. b) Send a outbound control message with the updated parameter value
In the above, if <bot>="All", then Bot41 should send a message to all bots.
On Timer: A timer should be set to perform the following actions at an interval specified by the parameter TimeOutTimer:
4) Check Active/Pending stack for time-out: a) If order status is Pending, i) If time since the last order was submitted exceeds AckResubmitTime and if the number of orders submitted is less than AckNumResubmit (1) Resubmit order (2) Issue exception ii) If time since original order was submitted exceeds AckTimeOut (1) Send a cancel order & move order to CancelPending stack (2) Issue exception b) If order status is Active and if Action = "IOC", i) If time since the last order was submitted exceeds IOCResubmitTime and if the number of orders submitted is less than IOCNumResubmit (1) Resubmit order (2) Issue exception ii) If time since original order was submitted exceeds IOCTimeOut (1) Delete order from Active/Pending stack (2) Issue exception c) If stack size exceeds ActiveStackWarnSize, issue a warning d) If stack size exceeds ActiveStackCriticalSize, issue an error and delete oldest order 5) Check CancelPending stack for time-out: a) If order status is CancelPending, i) If time since the last cancel request was submitted exceeds CancelResubmitTime and if the number of orders submitted is less than CancelNumResubmit (1) Resubmit cancel request (2) Issue exception ii) If time since original order was submitted exceeds CancelTimeOut (1) Delete order from CancelPending stack (2) Issue exception b) If stack size exceeds CancelStackWarnSize, issue a warning c) If stack size exceeds CancelStackCriticalSize, issue an error and delete oldest order 6) Check unprocessed exec report stack for time-out: a) If the time on the report exceeds the ExecRepTimeOut parameter i) Remove report from buffer
1 -NY/1922975.1 6g ii) Issue exception b) If stack size exceeds ExecRepStackWarnSize, issue a warning c) If stack size exceeds ExecRepStackCriticalSize, issue an error and delete oldest order
Bot41 Specifications
Input/Output Overview
Subscribes to: • New/cancel order messages from the BOTS • Acknowledgements and execution reports from DAR markets • Acknowledgements and execution reports from LEH markets • Settlement date message • Bot control requests to modify a Bot41 parameter
Publishes: • Execution reports to the Bots • New/cancel/cancelReplace orders to the DAR markets • New/cancel orders to the LEH markets • Inbound bot control messages to the Bots: settlement date changes to other bots • Outbound bot control parameter settings report o Dump of the internal cache from a SendCache request o Dump of Bot parameters o Changed values of Bot parameters • Bot41 Warning/Error Messages
Bot41 Parameters
Figure imgf000095_0001
1 -NY/1922975.1 67
Figure imgf000096_0001
The Bot41 parameters can be changed through control message sent to Bot41. 1-NY/1922975.1 68 Bot42 Engine
Background The Bot42 engine changes bot parameters according to a timer and/or to market events. Timers can be created and destroyed dynamically through control messages.
FIGURE 50 illustrates an embodiment for setting the parameters for "SpeedOrderSize" as controlled by the timers for Bot42. As shown, vertical lines indicate the times when trading is turned on and off respectively (8:00 and 17:00). From 8:10 to 8:30, the value of SpeedOrderSize is gradually increased from 0.5 to 1.0. From 16:00 to 16:40, the value is gradually decreased from 1.0 to 0.5.
Algorithm and Processing Flow
Processing Flow FIGURE 51 illustrates an embodiment for the processing flow for Bot4X.
Timers are created, updated and deleted through inbound control messages. Control messages sent to the bots are created by individual timers. There are two types of timers
• Ramp Timer • Binary Timer
The ramp timer allows for a gradual change in the parameter over a specified time period. The binary timer takes a discrete action at a single time point.
Global variables timerList = list of active timers bizDayCalendar = list of active business days
Binary Timer Specification
Binary Timer
Figure imgf000097_0001
The binary timer sends a single message to the bot at the specified time.
Binary Timer Object Initialization
if(recurring=NULL) recurring="None"; if(curTime>startTiiαe) error("Current time after startTime; no action today"); id = generateIDO ;
1-NY/l 922975.1 69 timerObj = createBinaryTimer(bot, ccyPair, parameter, time, value, recurring, id) ; addToList(timerObj, timerList) ;
Binary Timer Action
sendMessage(bot, ccyPair, parameter=value, RelativeValue=FALSE) ;
Recurring Timers If recurring- 'Daily" || "BizDay" || "EndOfWeek" || "StartOfWeek" , then the timer is activated every day or business day. Otherwise, the timer is deleted at the end of the last timer call.
Ramp Timer Specification
Figure imgf000098_0001
The ramp timer sends a series of messages over the time period changing a numeric parameter at a specified rate.
Ramp Timer Object Initialization / / creation of initial obj ect If (nlntervals I =NULL) { deltaT = duration/nlntervals ; } else if (deltaT I =NULL) { nlntervals = Math. round (duration/deltaT) ; deltaT = duration/nlntervals ; } else { error ( "Either nlntervals or deltaT must be specified" ) } if(recurring=NULL) recurring="None"; if(curTime>startTime) error("Current time after startTime; no action today");
id = generateID() ; timerObj = createRampTimer(bot, ccyPair, parameter, startTime, duration, nlntervals, deltaT, startValue, endValue, recurring, id); addToList(timerObj, timerList);
1-NY/1922975.1 70 Ramp Timer Action // each time timer steps to a new interval timerObj . curlnterval++ ; newValue = startValue + (endValue-StartValue) *curlnterval/nlnterval ; sendMeεsage (bot , ccyPair, paraiueter=newValue , RelativeValue=FALSE) ;
Business Days, End of Week, Start of Week Business days, end of week days and start of week days and are imported from the database when the bot is initialized or when the bot receives a RefreshCalendar control message.
Inbound Control Messages The following inbound control messages are supported
• DeleteTimer=id • NewBinaryTimer=( argl=value 1 , arg2=value2, ...) • NewRampTimer=( argl=valuel, arg2=value2,...) • UpdateTimer=(id, argl=valuel, arg2=value2,...) • RefreshCalendar
Bot Specification
Input/Output
Subscribes: • Settlement date message (timer) • Control messages to create and turn of timers
Publishes: • Control messages • Info/warning/error messages
Default Bot20, Bot51 Timers
Timer 1 : Trading On Type = Binary Time - 28800 (08:00:00) Parameter = "TradingOn" Value = "T" Recurring = "USBankDays"
Timer 2: Trading Off Type = Binary Time = 61200 (17:00:00) Parameter = "TradingOn" Value = "F" Recurring = "USBankDays"
Timer 3: Ramp up radius and stack size Type = Ramp
l-NY/1922975.1 71 Parameter = ("SpeedRadius", "SpeedTotalSize") StartTime = 30600 (08:30:00) Duration = 1800 (30 minutes) DeltaT = 90 (90 seconds) StartValue = "0.25" EndValue = "1.00" Recurring = "USBankDays"
Timer 4: Ramp up order size Type = Ramp Parameter = "SpeedOrderSize" StartTime = 30240 (08:40:00) Duration = 1200 (20 minutes) DeltaT = 90 (90 seconds) StartValue = "0.5" EndValue = "1.00" Recurring = "USBankDays"
Timer 5: Ramp down radius and stack size Type = Ramp Parameter = ("SpeedRadius", "SpeedTotalSize") StartTime = 57600 (16:00:00) Duration = 3600 (60 minutes) DeltaT = 180 (3 minutes) StartValue = "1.00" EndValue = "0.25" Recurring = "USBankDays"
Timer 6: Ramp down order size Type = Ramp Parameter = "SpeedOrderSize" StartTime = 57600 (16:00:00) Duration = 2400 (40 minutes) DeltaT = 180 (3 minutes) StartValue = "1.00" EndValue = "0.5" Recurring = "USBankDays"
Bot50 Engine Background
FIGURE 52 illustrates Bot50 prices and parameters for each roll stack.
Bot50 is responsible for putting in orders into the roll stacks. Let day 1, day 2 and day 3 be the next three settlement dates. Then the roll stacks are rolll and roll2 where
l-NY/1922975.1 72 rolll moves orders from day 1 to day 2 roll2 moves orders from day 2 to day 3
The orders are initially submitted at the maximum size for each price, e.g., maxSizel for price BidPricel. The prices are computed from the parameters FairValue, Radius, and the price deltas. Logisitics of a Roll
Let day 1, day 2 and day 3 be the next three settlement dates. Then the two roll stacks are rolll and roll2 where
rolll moves orders from day 1 to day 2 roll2 moves orders from day 2 to day 3
One roll transaction generates 4 tickets. For example, suppose a roll is executed for settlement day 1 to settlement day 2 at 0.10. Then we have two sides to the trade:
Side 1 = Buy 5,000,000 at 0.010 Side 2 = Sell 5,000,000 at 0.010
Side 1 gets a sell ticket for 5,000,000 at mid-market and a buy ticket for 5,000,000 at the mid-market+roll price
Side 2 gets a buy for 5,000,000 of the contract at mid-market and a sell ticket for 5,000,000 at mid-market+roll price.
As a result of these transactions, Side 1 moved its position from settlement day 1 to settlement day 2by paying the roll price. Side 2 moved its position from settlement day 2 to settlement day 1 and received a premium. Fair Value from Repo Rate Differential
Interest Rate Parity and Fair Value of Roll Let
X/Y = currency pair P = fair value for the spot rate: price of Y in currency X F = fair value for the forward price for a spot-next contract rx = overnight repo rate for X ry = overnight repo rate for Y ΓΛ = Xy- rx= interest rate differential
The interest rate parity relationship determines the forward price (see Hull, equation 3.14, p. 63):
F = P x exp(rΔ/ 365)
The fair value of the roll from spot to spot-next is
R = F - P
1 -NY/1922975.1 73 = P x (exp(rΔ/ 365) - l)
Example: EUR/USD Let
X/Y = EURAJSD P = 1.2760 rΔ = -0.00997
Then
R = -0.000035 = -.35 basis points
Example: USD/JPY Let
X/Y = USD/JPY P = 106.18 rΔ = -.O118
Then
R = -0.0034 = -.34 basis points
Market Close At market close (6pm), the rolll orders are expired and the roll2 orders are moved to the rolll stack. An exception to this rule occurs when ON=TN; in this case, the roll2 stack is expired and the rolll stack is left empty. Parameters
Figure imgf000102_0001
l-NY/l 922975.1 74
Figure imgf000103_0001
The target prices are computed as follows:
rollXTargetBidl = rollXFairValue - rollXRadius - rollXbidDeltal rollXTargetBid2 = rollXPairValue - rollXRadius - rollXbidDelta2 rollXTargetAskl = rollXFairValue + rollXRadius + rollXAskDeltal rollXTargetAsk2 = rollXFairValue + rollXRadius + rollXAskDelta2
If autoUpdateFV=TRUE , then the fair value for both rolls is computed from IRDelta using the IR parity formula:
rollXFairValue = 10a x (spotFairValue x (exp(IRDeIta / 365) - I))
where io"d = price value of a basis point (so d=4 for EUR/USD and d=2 for USD/JPY).
-Bot51 Engine
Overview Bot51 supersedes Bot50, and is responsible for putting in orders into the roll stacks. It is a clone of Bot20 with the following differences:
• Instead of inputting fair value from market prices, as in Bot20, Bot51 determines fair value from overnight repo rates using the interest rate parity relationship. The radius is taken from a parameter value. • Prices for rolls are in 10th's of a basis point, not integer basis points (as with Bot20). • There is no check for order pick-off. • At the close of trading, Bot51 rolls orders from the roll2 stack to the rolll stack (as in Bot50). The roll2 stack is reinitialized.
BackGround
Logistics of a Roll: Let day 1, day 2 and day 3 be the next three settlement dates. Then the two roll stacks are rolll and roll2 where
rolll moves orders from day 1 to day 2 roll2 moves orders from day 2 to day 3
1 -NY/1922975.1 75 One roll transaction generates 4 tickets. For example, suppose a roll is executed for settlement day 1 to settlement day 2 at 0.10. Then we have two sides to the trade:
Side 1 = Buy 5,000,000 at 0.010 Side 2 = Sell 5,000,000 at 0.010
Side 1 gets a sell ticket for 5,000,000 at mid-market and a buy ticket for 5,000,000 at the mid-market+roll price
Side 2 gets a buy for 5,000,000 of the contract at mid-market and a sell ticket for 5,000,000 at mid-market+roll price.
As a result of these transactions, Side 1 moved its position from settlement day 1 to settlement day 2 by paying the roll price. Side 2 moved its position from settlement day 2 to settlement day 1 and received a premium.
Interest Rate Parity and Forward Contracts Let
X/Y = currency pair P = current spot rate: price of Y in currency X F = forward price for a one-day ahead contract K = delivery price of the forward contract rx = overnight repo rate for X ry = overnight repo rate for Y μ = value of forward contract
Then the interest rate parity relationship determines the forward price (see Hull, equation 3.14, p. 63):
F = P x exp(rx - ry)
The value of the forward contract is (Hull, equation 3.11, p. 55):
μ = (F-K) x exp(-ry)
(1)
Example: One-Day Forward Contract for EUR/USD
Suppose the spot price of the EUR/USD is 1.088 and we assume the delivery price is equal to the spot price. Then
X = EUR Y = USD P = K =1.0880 rx = 0.01128 ry = 0.005
1-NY/1922975.1 76 F = 1.08793 μ = -0.000068
Hence, the value of the forward contract is -0.68 basis points.
Market Close At market close (6pm), the rolll orders are expired and the roll2 orders are moved to the rolll stack. An exception to this rule occurs when ON=TN; in this case, the roll2 stack is expired and the rolll stack is left empty.
Algorithm and Processing Flow
Processing Flow
FIGURE 53 illustrates an embodiment of the processing flow for Bot51.
FIGURE 53 depicts the processing flow for Bot51. Bot51 responds to three events: an execution report, an updated parameter or a new fair value from BotlO. If the repo rate parameters are updated, or if a new fair value for the spot price is input, then Bot51 updates fair value for the rolls. After all events, Bot51 updates the stack thresholds, cancels orders outside the thresholds and refills the stacks.
Random Order Generator and Parameters:
FIGURE 54 illustrates the distribution of stacks for a roll.
Orders are generated randomly according to a random distribution as depicted above in FIGURE 54. The generator is identical to that used in Bot20.
The thresholds in FIGURE 54 are computed from fair value and the radius from the parameters as follows:
bidCancelThresh = FairValue - bidDelta - bidRadiusMult x Radius bidNewThresh = FairValue - bidNewDelta - bidNewRadiusMult x Radius askCancelThresh = FairValue + askDelta + askRadiusMult x Radius askNewThresh = FairValue + askNewDelta + askNewRadiusMult x Radius
The parameters bidGapl and askGapl in FIGURE 54 are used to constrain Bot51 to have orders within bidCancelThresh and askCancelThresh respectively.
Computation of Fair Value In the absence of market supply and demand information, we set fair-value to the value of a one-day forward contract μ as fair value for the rolls. Use equation (1) to compute μ with
l-NY/1922975.1 77 rx = parm.repoRatel Xy = parm.repoRate2 P = fairValue of spot currency X/Y K = P
Variables and Parameters
Parameters
Local Cache
External Cache
Order Book
Bot Specification
Inputs and Outputs
Subscribes to: • Execution reports on Bot51 orders • Fair value from BotlO • Bot control request
Publishes: • New order messages • Cancel order messages • Parameter settings report
Future Enhancements Future enhancements to Bot51 include:
1. Set fair value and the radius from a real-time feed supplying normalized repo rates. 2. Add in speed parameters 3. Add in order time outs
BotδX Engine
Background
FIGURE 55 illustrates an embodiment of the operation of Bot5X engines.
The Bot5X manages the stacks for manual trades submitted from the game pad and other devices. The engine receives new order and cancel requests from Bot40. For a cancel order, the bot identifies which orders to cancel out of the stacks and sends an cancel order message to the appropriate stack.
1 -NY/1922975.1 73 The Bot5X engine has no parameters. Parameters for manual trading are primarily contained in Bot40 and other trading interfaces.
FIGURE 56 illustrates an embodiment of the input and output messages and processing flow for Bot5X engines.
Inputs
Execution/Acknowledgement Report t
BOT50: Stack Message Subject: "LEH.EFX.MLN.DEALS.OUT.<type>.LEHMAN.BOT50.8" <type> = FILL or ACK
Required Fields
Figure imgf000107_0001
BOT51 : DAR Message Subject: "Appia.MERLIN_FX.OUT.LEH_EFX.8" Re uired Fields
Figure imgf000107_0002
Bot Control Request If a Bot Control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols. If a Bot Control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
If a bot control message has CancelTop = "Bid" or "Ask", then an order is cancelled from the top of the stack. If a bot control message has CancelAll CancelTop = "Bid" or "Ask", then the entire stack is cancelled.
1 -NY/1922975.1 79 If a bot control message has OrderType = "Bid" | "Ask" | "Buy" | "Sell", then an order is submitted. The price and size are given by the fields OrderPrice and OrderSize.
Message Subject "LEH.MERLIN.CTRL.<bot>.<symbol>.IN" <bot> = "BOT50" I "B0T51" <symbol> = "ALL" | λΕUR/USD" | "EUR/JPY" | "USD/JPY"
Message Format
Figure imgf000108_0001
Settlement Date
Message Subject: 11LEH.EFX.MLN.SETTLE.OUT.<symbol>'
Required Fields:
Figure imgf000108_0002
Outputs
New Order Message
BOT50: Stack New Order
1 -NY/1922975.1 80 Message Subject "LEH.EFX.MLN.DEALS.IN.LEHMAN.BOT50.D" Messa e Format;
Figure imgf000109_0001
BOT51 : DAR New Order Message Subject: "Appia.MERLIN_FX.IN.LEH_EFX.D" Messa e Format:
Figure imgf000109_0002
1 -NY/1922975.1 81 Cancel Order Message BOT50: Stack Cancel Message Subject "LEH.EFX.MLN.DEALS.IN.LEHMAN.BOT50.F" Message Format:
Figure imgf000110_0001
BOT51 : DAR Cancel Message Subject: "Appia.MERLIN_FX.IN.LEH_EFX.D" Message Format:
Figure imgf000110_0002
1 -NY/1922975.1 82
Figure imgf000111_0001
Bot5X Activity Message
Message Subject "LEH.MERLIN.<bot>.INFO.<symbol>.ACTIVITY" <bot> = "BOT50" I "BOT51" < symbol > = "EUR/USD" | "EUR/ JPY" | "USD/ JPY" "ALL"
Figure imgf000111_0002
Classes
Cache
Figure imgf000111_0003
Engines
Bot5X
Subscribes to: • Execution report • Cancel top-of-stack request • Settlement date
Publishes: • Cancel Order • Bot5X Activity Report
Bot60 Price Filter Background FIGURE 57 illustrates an embodiment of price filter inputs, intermediate calculations and outputs.
Inputs PAR price message
Message Subject: "LEH.EFARM.PRICE.FX.SPOT.<symbol>.DAR.MLN.RAW.UPDATE" <syrabol> = "EURUSD" or "EURJPY" or "USDJPY".
1-NY/1922975.! 83 Required Fields:
Figure imgf000112_0001
Bot Control Request If a Bot Control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a Bot Control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
Message Subject "LEH.MERLIN.CTRL.BOT60.<column>.IN" <coluτnn> = "ALL" | "EUR/USD" I "EUR/JPY" "USD/JPY"
Message Format
Figure imgf000112_0002
Outputs Price Broadcast
Message Subject: "LEH . MERLIN . PRI CE . BOT60 . <symbol> " <symbol > = "EURUSD" or "EURJPY" or "USDJPY"
Figure imgf000112_0003
1 -NY/1922975.1 84 Parameter Settings Report The Bot60 filter publishes its current parameter settings if a Bot Control message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified. If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting. Message Subject: parameter refresh messages: ULEH . MERLIN . CTRL . BOT6 O . < coiumn> . OUT " <column> = "ALL" | "EUR/USD" | "EUR/JPY" | "USD/JPY" Required Fields
Figure imgf000113_0001
Classes and Variables Bot60 Variables
Figure imgf000113_0002
Mappings to IMSL routine
Figure imgf000113_0003
1-NY/1922975.1 85
Figure imgf000114_0001
Mapping from Kalman Output to Broadcast Message
C = 10A-digits FairValue = C*StateVec[0] ; BidRadius = C*(Delta+StateVec[1] ) ; AskRadius = C*(Delta+StateVec[2] ) ; // // compute broadcast prices askBroadcastRadius = min(askBroadcastRadiusMax*C, AskRadius*askBroadcastRadiusMult + askBroadcastDelta*C) ; bidBroadcastRadius = min(bidBroadcastRadiusMax*C, BidRadius*bidBroadcastRadiusMult + bidBroadcastDelta*C) ; BroadcastAsk = round2digits(FV + askBroadcastRadius, digits); BroadcastBid = round2digitε (FV - bidBroadcastRadius, digits) ; // // compute standard deviations BidSD = C*(StateCov[0,0] - 2*StateCov[0,1] + StateCov[l,1] ) ; AskSD = C*(StateCov[0,0] + 2*StateCov[0,2] + StateCov[2,2] ) ;
Bot7X Engine
Background FIGURE 58 illustrates an embodiment of how the radius multiplier for Bot70 decreases over the live span of an order.
FIGURE 59 illustrates an embodiment of how a time interval for an order is determined by the time and number of orders remaining.
FIGURE 60 illustrates an exemplary processing flow for Bot70.
FIGURE 61 illustrates a secondary processing flow for Bot70.
Algorithm Description
Variables and Parameters
Parameters
Figure imgf000114_0002
1-NY/19Z2975.1 86
Figure imgf000115_0001
Internal State Cache globalStartTime : Start time for the total order nOrders : Number of remaining orders timeStart : Starting time for the current working order t imeEnd : Target end time for the current working order
Order Book Cache cur S i z e : Size of current order curPrice : Price of current order cur ID : ID of current order
External State Cache f airValue : Fair value as input from the price filter radius : Radius as input from the price filter
Local Variables cumSize : Cumulative total fill size timeRemain : Total time remaining to work all orders curTime : Current time openOrder : if TRUE, then we have an open order newPrice : New price based on updated delta delta : Delta off of fair value at which to compute the new price
Pseudocode: Primary Engine
Initialization cumSize = 0; curSize = 0; globalStartTime = curTime; nOrders = Math.ceil(totalSize/orderSize) ;
1-NY/1922975.1 87 Update cumSize and curSize: cumSize = cumSize + fillSize; curSize = curSize — fillSize;
New Interval (curSize <= 0) openOrder = FALSE
Last Interval (nθrders==l)
Reset if New Interval timeRemain = totalTime - (curTime - globalStartTime) ; sizeRemain = totalSize - cumSize; nOrders = Math.ceil(sizeRemain/orderSize) ; timeStart = curTime; if(nθrders==l | | timeRemain<=0) timeEnd = globalStartTime + totalTime; else{ timeEnd = curTime+timeRemain* (1/nOrders + workTimeFrac/(nOrders-1) ) ; } curSize = min(orderSize, sizeRemain);
Switch to idle cancelAllOrders() ; setParameter(tradingOn=FALSE) ;
Update multiplier // recomputed the end of the interval and time remaining in case // total time has changed timeRemain = totalTime - (curTime - globalStartTime) ; if(nθrders==l | | timeRemain<=0) timeEnd = globalStartTime + totalTime; else{ timeEnd = timeStart + (totalTime - (timeStart - globalStartTime) )*(1/nOrders + workTimeFrac/(nOrders-1)) ; } // local time determines how much time we have left to work an order if(timeRemain>0) localTime = (curTime - timeStart) /(timeEnd-timeStart) ; else localτime=100.0; // past the ending time for the interval C = 10Λ-nDigits; if(localTime > 1){ roundup = isBid; delta = C*max(minDelta, - (curTime-timeEnd)/improvePriceTime) ; } else { roundup = ϋsBid; delta = C*deltaO + radius * maxRadiusMult * powerTransform(localTime, multPower) ; } // update price if(isBid) newPrice = fairValue - delta; else newPrice = fairValue - delta; if(roundup) newPrice = ceilToDigits(newPrice, nDigits) ; else newPrice = floorToDigits(newPrice, nDigits);
1-NY/1922975.1 New Order // new order if current order size is changed or current price is // further away than target price newOrder = (isBid && (newPrice > curPrice) ) | | (isAsk && (newPrice < curPrice))
Submit Order; curPrice = newPrice; if(ldap.cancelReplaceMode && openOrder) submitOrder(curPrice, curSize, id=curID, action="cancelReplace") ; else{ if(openOrder) cancelOrder(id=curlD) ; curID = generateIDO ; submitOrder(curPrice, curSize, id=curID, action="newOrder") ; } openOrder = TRUE;
Psuedocode: Initialization of Secondary Engine The order book is imported from Bot41. The local variables are initialized as follows:
cumSize = totalSize-nθrders*orderSize-curSize if (curSize>0) openOrder = TRUE; else openOrder = FALSE;
Inputs The inputs are the same as those for Bot50 except that Bot70 subscribe to normalized prices (like Bot20).
Execution Report On receipt an execution report, Bot70 updates the order size. If LeavesQty = 0, then the order is completely filled and removed from the open order queue.
Message Subject "LEH.EFX.MLN.DEALS.OUT.FILL.LEHMAN.BOT70.8"
Required Fields
Figure imgf000117_0001
Filtered Price Message
1 -NY/1922975.1 89 Message Subject "LEH.MERLIN.PRICE.FX.SPOT.<symbol>.NORMB" <symbol> = "EXIRUSD" or "EURJPY" or "USDJPY"
Required Fields
Figure imgf000118_0001
Settlement Date
Message Subject
"LEH.EFX.MLN.SETTLE.OUT.<symbol>'
Required Fields:
Figure imgf000118_0002
Bot Control Request If a Bot Control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a Bot Control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
If a bot control message has CancelTop = "Bid" or "Ask", then an order is cancelled from the top of the stack. If a bot control message has CancelAU CancelTop = "Bid" or "Ask", then the entire stack is cancelled.
Message Subject "LEH . MERLIN . CTRL . BOT70 . <symbol> . IN" <symbol> = "ALL" | "EUR/USD" | "EUR/JPY" | "USD/JPY"
Outputs
Cancel/New Order Message A new order message is sent when the total size for a price falls below the minimum threshold.
1-NY/1922975.1 90 A cancel order message is sent when trading is turned off.
Message Subject New order messages: " LEH . EFX . MLN . DEALS . IN . LEHMAN . BOT7 O . D " Cancel order messages: » LEH . EFX . MLN . DEALS . IN . LEHMAN . BOT7 O . F Ij
Message Format
Figure imgf000119_0001
Parameter Settings Report Bot70 publishes its current parameter settings if a Bot Control message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified.
If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting.
Message Subject: parameter refresh messages: "LEH . MERLIN . CTRL . BOT7 O . < coiumn> . OUT »
<coluran> = "ALL" | "EUR/USD" | "EUR/JPY Ii 1 u USD/JPY"
Bot70Info Message
Message Subject "LEH.MERLIN.BOT70.INFO.<<activitytype>>" <<activitytype>> = "NOTRADE" | "TRADE"
Classes TBD
Engines
Bot70Manager
Subscribes to: • Execution report • Filtered Prices • Bot control request • Settlement date message
1-NY/1922975 1 91 Publishes: • New order messages • Cancel order messages • Parameter settings report
1 -NY/1922975.1 92 Bot70(V2) Engine
Background
FIGURE 62 illustrates an emobidment of how the radius multiplier for Bot70 decreases over the live span of an order.
FIGURE 63 illustrates how the time interval for an order is determined by the time and number of orders remaining.
FIGURE 64 illustrates an exemplary processing flow for Bot70.
FIGURE 65 illustrates a secondary processing flow for Bot70.
Variables and Parameters
Parameters
Figure imgf000121_0001
Internal State Cache TargetSσhedule [ , ] : Scheduled target times (column 1) at which to sell a specified quantity (column 2)
Order Book Cache OrderList [] : Current list of active orders
External State Cache FairValue : Fair value as input from the price filter Radius : Radius as input from the price filter DarBidPrice : best bid from DAR
1 -NY/1922975.1 93 DarAskPrice: best ask from DAR
Local Variables CurTime : Current time TargetPrice : Current best target price based on updated delta
Algorithm and Pseudocode
ProcessCtrlMsgO: changes to the parameters and to the target quantity are made through control messages UpdateTargetScheduleO: changes to the parameters and to the target quantity are made through control messages UpdateDarPriceO: update market data cache with new prices ProcessDarExecRepO: update order book with fills/cancels/rejects Updateθrders(): main processing flow updating the active order book as necessary
QtyRateø: target trade quantity per minute OverDueQtyO: quantity overdue AlmostDueQtyO: quantity almost overdue Cancel AHQ: cancel all orders
ProcessCtrlMsgfmsg^ Update = FALSE; // check if the action has changed from buy to sell/sell to buy If(msg.TargetSideI=NTJLL && TargetSide != msg.side){ CancelAllO ; TargetSchedule = NULL; Update = TRUE; } // check if the action has changed from buy to sell/sell to buy If(msg.TargetQuantity!=NULL && TargetQty I= msg.TargetQty) { TargetQty = msg.TargetQty; If(TargetQty <= 0) CancelAll() ; Update = TRUE; > If(Update) UpdateTargetSchedule(TargetSchedule, TargetSide, TargetQty);
UpdateTargetSchedule(Schedule, Side, Quantity) // initialize a new schedule If(Schedule = NULL) {
Switch to idle cancelAllOrdersO ; setParameter(tradingOn=FALSE) ;
Update multiplier // recomputed the end of the interval and time remaining in case // total time has changed timeRemain = totalTime - (curTime - globalStartTime) ;
1 -NY/1922975.1 94 if(nθrders==l || timeRemain<=0) timeEnd = globalStartTime + totalTime; else{ timeEnd = tiπieStart + (totalTime - (timeStart - globalStartTime))*(1/nOrders + workTimeFrac/(nθrders-1) ) ; } // local time determines how much time we have left to work an order if(timeReitιain>0) localTime = (curTime - timeStart)/(timeEnd-timeStart) ; else localτime=100.0; // past the ending time for the interval C = 10A-nDigits; if(localTime > 1) { roundup = isBid; delta = C*max(minDelta, -(curTime-timeEnd)/improvePriceTime) ; } else { roundUp = !isBid; delta = C*deltaO + radius * maxRadiuεMult * powerTransform(localTime, multPower) ; } // update price if(isBid) newPrice = fairValue - delta; else newPrice = fairValue - delta; if(roundup) newPrice = ceilToDigits(newPrice, nDigits) ; else newPrice = floorToDigits(newPrice, nDigits);
NewOrder // new order if current order size is changed or current price is // further away than target price newOrder = (isBid && (newPrice > curPrice)) || (isAsk && (newPrice < curPrice) )
Submit Order; curPrice = newPrice; if(ldap.cancelReplaceMode && openOrder) submitOrder(curPrice, curSize, id=curID, action="cancelReplace") ; else{ if(openOrder) cancelOrder(id=curID) ; curID = generateIDO ; submitOrder(curPrice, curSize, id=curID, action="newOrder") ; } openOrder = TRUE;
Psuedocode: Initialization of Secondary Engine The order book is imported from Bot41. The local variables are initialized as follows:
cumSize = totalSize-nθrders*orderSize-curSize if(curSize>0) openOrder = TRUE; else openOrder = FALSE;
Inputs The inputs are the same as those for Bot50 except that Bot70 subscribe to normalized prices (like Bot20).
Execution Report On receipt an execution report, Bot70 updates the order size. If LeavesQty = 0, then the order is completely filled and removed from the open order queue.
1 -NY/! 922975.1 95 Message Subject "LEH.EFX.MLN.DEALS.OUT.FILL.LEHMAN.BOT70.8'
Required Fields
Figure imgf000124_0001
Filtered Price Message
Message Subject "LEH.MERLIN.PRICE.FX.SPOT.<symbol>.NORMB" <symbol> = "EURUSD" or "EURJPY" or "USDJPY"
Figure imgf000124_0002
Settlement Date
Message Subject
"LEH.EFX.MLN.SETTLE.OUT.<symbol>'
Required Fields:
Figure imgf000124_0003
Bot Control Request If a Bot Control message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a Bot Control message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
If a bot control message has CancelTop = "Bid" or "Ask", then an order is cancelled from the top of the stack. If a bot control message has CancelAll CancelTop = "Bid" or "Ask", then the entire stack is cancelled.
Message Subject "LEH.MERLIN.CTRL.BOT70.<symbol>.IN" <symbol> = "ALL" | "EUR/USD" | "EXJR/JPY" | "USD/JPY"
Outputs
Cancel/New Order Message A new order message is sent when the total size for a price falls below the minimum threshold.
A cancel order message is sent when trading is turned off.
Message Subject New order messages: " LEH . EFX . MLN . DEALS . IN . LEHMAN . BOT7 o . D " Cancel order messages: " LEH . EFX . MLN . DEALS , IN . LEHMAN . BOT70 . F" \
Message Format
Figure imgf000125_0001
Parameter Settings Report Bot70 publishes its current parameter settings if a Bot Control message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified.
If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting.
Message Subject: parameter refresh messages: "LEH . MERLIN . CTRL . BOT7 O . < column> . OUT "
l-NY/l 922975.1 97 <column> = "ALL" I "EUR/USD" | "EUR/JPY" | "USD/JPY"
Bot70Info Message
Message Subject "LEH.MERLIN.BOT70.INFO.<<activitytγpe>>" <<activitytype>> = "NOTRADE" | "TRADE"
Classes TBD
Engines
Bot70Manager
Subscribes to: • Execution report • Filtered Prices • Bot control request \ • Settlement date message
Publishes: • New order messages • Cancel order messages • Parameter settings report
Bot80 Engine
Background The Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
Basics
Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have
Bid EUPJJPY « Bid EUR/USD x Bid USD/JPY Ask EUR/JPY « Ask EUR/USD x Ask USD/JPY
An arbitrage opportunity arises if
1 -NY/1922975.1 9g Bid EUR/JPY > Ask EUR/USD x Ask USD/JPY
In this case, we can exploit the opportunity by selling the "primary" currency EUR/JPY and buying the "arb" currencies EUR/USD and USD/JPY. This is depicted in FIGURE 66.
Similarly, we have an arbitrage opportunity if
Ask EUR/JPY < Bid EUR/USD x Bid USD/JPY
This situation is depicted in FIGURE 67.
FIGURE 66 illustrates a type 1 arbitrage.
FIGURE 67 illustrates a type 2 arbitrage.
Trading Lot Size Residual A complication in the triangular arbitrage is the constraint that we trade in fixed lot sizes. This will mean that even we execute a triangular arbitrage successfully (i.e.. all three currencies are traded), we still end up with a residual from the trade. Let
Pe¥= trade price for EUR/JPY Pe$ = trade price for EUR/USD P$¥= trade price for USD/JPY
Then if we buy one million in EUR/JPY and sell one million EUR/USD and USD/JPY, then we end up with a zero balance for EUR and JPY but a non-zero balance for USD:
USD residual = 1,000,000 x (1-1/P€$)
The size of the residual depends on how close the EUR/USD is to parity (Pe$=l).
Multiple Markets In principle, the extension to multiple markets is straightforward. The arbitrage is based on the composite best bid and best ask for each currency pair as the best ask and best bid across all markets. Two complications arise, however, when we extend to multiple markets:
1. The tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2. The transaction cost and execution performance is not the same across all markets.
FIGURE 68 illustrates an exemplary processing flow for Bot8X. In an embodiment, if there are no open Bot8X orders, then Bot8X looks for an arbitrage opportunity.
FIGURE 69 illustrates a secondary processing flow for Bot8X.
Algorithm and Processing Flow The primary and secondary processing flows are shown in FIGURES 68 and 69.
I-NY/1922975.1 99 Parameters and Variables
Parameters S mbol S ecific
Figure imgf000128_0001
Internal Cache lastOrderTime = last time an order was submitted
External Cache P = number of markets askPx = P x 3 matrix of (best) ask prices from each market & currency pair askSz = P x 3 matrix of sizes at the (best) ask for each market & currency- pair bidPx = P x 3 matrix of (best) bid prices from each market & currency pair bidSz = P x 3 matrix of sizes at the (best) bid for each market & currency pair Iask = vector of length 3 giving the index of market that gives the composite best ask for each currency pair Ibid = vector of length 3 giving the index of market that gives the composite best bid for each currency pair
OrderBook orderList = list of open orders
Local Stateless Variables arbBid = arbitrage bid price arbAsk = arbitrage ask price executeArb = if TRUE, then an arb should be executed openOrder = if TRUE, then an order is open needToWait = if TRUE, need to wait before submitting a new order primarySide = side of the order for the primary currency pair arblSide = side of the order for the arbl currency pair arb2Side = side of the order for the arb2 currency pair orderSize = size of the order
1-NY/19M975.1 100 Algorithm and Pseudocode
Functions: minRowlndex(double iαat[] [] , long j) : returns row with the minimum value in column j maxRowlndex(double mat[] [] , long j) : returns row with the maximum value in column j submitOrder(enum market, enum orderType, enum symbol, enum side, double price, long side) : submit an order to the specified market
Arb Calculation: // index of market with composite best bid and ask For(j=0; j++; j<3){ Iask[j] = minRowlndex(askPx.j) ; Ibid[j] = maxRowlndex(bidPx,j) ; } // compute arbitrage price if(arb2Action=="same") { arbBid = bidPx[Ibid[l] ,1] * bidPx[Ibid[2] ,2] ; arbAsk = askPx[Iask[l] ,1] * askPx[Iask[2] ,2] ; } else { arbBid = bidPx[Ibid[l] ,1] / askPx[Iask[2] ,2] ; arbAsk = askPx[Iask[l] ,1] / bidPx[Ibid[2] ,2] ; } // determine if arbitrage type 1 is present: buy arb, sell primary if(bidPx[Ibid[0] ,0] - arbAsk >= Parm.arbMinDelta) { executeArb=T; primarySide = 2; ■ _ | arblSide = "bid";; if(arb2Action=="same") { arb2Side = "bid";; arb2Size=askSz [Iask [2 ] , 2] ; } else { t arb2Side = "ask" ; arb2Size=bidSz [Ibid [2] , 2] ; } orderSize = Min (bidSz [Ibid [0 ] , 0] , askSize [Iask [l] , 1] , arb2Size , Parm. maxOrderSize) ; } // determine if arbitrage type 1 is present: sell arb, buy primary if(arbBid-askPx[Iask.0] ,0] >= Parm.arbMinDelta){ executeArb=T; primarySide = "ask"; arblSide = "ask"; if(arb2Action=="same") { arb2Side = "ask"; arb2Size=askSz[Iask[2] , 2]; } else { arb2Side = "bid" ; arb2Size=bidSz [Ibid [2] , 2] ; } orderSize = Min (askSz [Iask [ 0] , 0] , bidSize [Ibid [l] , 1] , arb2Size) ; }
Submit Trades: needToWait = curTime - lastOrderTime <= Parm.minWaitTime if(orderList = NULL) openOrder = FALSE
! -NY/19212975.1 101 else openOrder = TRUE // submit a trade if we have an arb opportunity, there are no // open orders , and we don' t need to wait if (executeArb && I openOrder && ! needToWa.it) { lastOrderTime = curTime ; //submit order to primary market if (primarySide==l) submitOrder (market=Ibid [0] , type=Parm. orderType [ 0] , symbol=Parm. symbolPrimary, side="bid" , price=askPx [Iask [0] ] +Parm.priσeDelta [0] , size=OrderSize) ; else submitOrder (market=Iask [0] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [0] ] -Parm.priceDelta [0] , size=OrderSize) ; //submit order to arbl market if (arblSide==l) submitOrder (market=Ibid [l] , type=Parm. orderType [1] , sytnbol=Parm. symbolPrimary, side="bid" , price=askPx [Iask [l] ] +Parm. priceDelta [l] , size=OrderSize) ; else submitOrder (market=Iask [l] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [l] ] -Parm. priceDelta [1] , size=OrderSize) ; //submit order to arb2 market if (arb2Side==l) submitOrder (market=Ibid [2] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="bid" , price=askPx [Iask [2] ] +Parm.priceDelta [2] , size=OrderSize) ; else submitOrder (market=Iask [2] , type=Parm. orderType [ 0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [2] ] -Parm.priceDelta [2] , size=θrderSize) ; }
Bot Specification
Subscriptions and Publications Bot8X subscribes to the following messages
• Price Feed Updates (one for each market) • Order Execution Reports (one for each market) • Bot Parameter Control Updates
BotδX publishes the following messages:
• New Order Messages • Control Parameter Settings Report • Bot8X Activity Messages
Bot80 Bot80 subscribes and publishes to just DAR. The price feed is the DAR feed
Message Details See the spreadsheet tibFormats.xls for details of all messages. This section describes details of the messages in terms of how they are used in BotSX.
PAR Price message
Figure imgf000130_0001
l-NY/1922975.1 102
Figure imgf000131_0001
Stack Price message
Figure imgf000131_0002
BotδO Engine
Background The Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
Basics
Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have
Bid EUPJJPY « Bid EUR/USD x Bid USD/JPY Ask EUR/JPY » Ask EUPJUSD x Ask USD/JPY
An arbitrage opportunity arises if
Bid EUPJJPY > Ask EUR/USD x Ask USD/JPY
In this case, we can exploit the opportunity by selling the "primary" currency EUR/JPY and buying the "arb" currencies EUR/USD and USD/JPY. This is depicted in FIGURE 70.
Similarly, we have an arbitrage opportunity if
Ask EUR/JPY < Bid EUR/USD x Bid USD/JPY
1 -NY/1922975.1 103 This situation is depicted in FIGURE 71.
FIGURE 70 illustrates a type 1 arbitrage.
FIGURE 71 illustrates a type 2 arbitrage.
Trading Lot Size Residual A complication in the triangular arbitrage is the constraint that we trade in fixed lot sizes. This will mean that even we execute a triangular arbitrage successfully (i.e.. all three currencies are traded), we still end up with a residual from the trade. Let
Ps= trade price for EUR/JPY Pe$ = trade price for EUR/USD P$¥ = trade price for USD/JPY
Then if we buy one million in EUR/JPY and sell one million EUR/USD and USD/JPY, then we end up with a zero balance for EUR and JPY but a non-zero balance for USD:
USD residual = 1,000,000 x (1-1/Pe$)
The size of the residual depends on how close the EUR/USD is to parity (Pe$=l).
Multiple Markets In principle, the extension to multiple markets is straightforward. The arbitrage is based on the composite best bid and best ask for each currency pair as the best ask and best bid across all markets. Two complications arise, however, when we extend to multiple markets:
1. The tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2. The transaction cost and execution performance is not the same across all markets.
FIGURE 72 illustrates an exemplary processing flow for Bot8X. In an embodiment, if there are no open Bot8X orders, then Bot8X looks for an arbitrage opportunity.
FIGURE 73 illustrates a secondary processing flow for Bot8X.
Algorithm and Processing Flow The primary and secondary processing flows are shown in FIGURES 72 and 73.
Parameters and Variables
Parameters S mbol S ecific
Figure imgf000132_0001
1 -NY/1922975.1 104
Figure imgf000133_0001
Internal Cache lastOrderTime = last time an order was submitted
External Cache number of markets askPx = P x 3 matrix of (best) ask prices from each market & currency pair askSz = P x 3 matrix of sizes at the (best) ask for each market & currency pair bidPx = P x 3 matrix of (best) bid prices from each market & currency pair bidSz = P x 3 matrix of sizes at the (best) bid for each market & currency pair Iask = vector of length 3 giving the index of market that gives the composite best ask for each currency pair Ibid = vector of length 3 giving the index of market that gives the composite best bid for each currency pair
OrderBook orderXiist = list of open orders
Local Stateless Variables arbBid = arbitrage bid price arbAsk = arbitrage ask price executeArb = if TRUE, then an arb should be executed openOrder = if TRUE, then an order is open needToWait = if TRUE, need to wait before submitting a new order primarySide = side of the order for the primary currency pair arblSide = side of the order for the arbl currency pair arb2Side = side of the order for the arb2 currency pair orderSize = size of the order
Algorithm and Pseudocode
Functions: minRowlndex(double mat[] [] , long j) : returns row with the minimum value in column j maxRowlndex(double mat[] [] , long j) : returns row with the maximum value in column j
1-NY/1922975.1 105 submitOrder(enum market, enum orderType, enum symbol, enuiα side, double price, long side) : submit an order to the specified market
Arb Calculation: // index of market with composite best bid and ask For(j=0; j++; j<3) { Iask[j] = minRowIndex(askPx.j) ; Ibid[j] = maxRowIndex(bidPx,j) ; } // compute arbitrage price if(arb2Action=="same") { arbBid = bidPx .Ibid tl] , 1] * bidPx [Ibid [2] , 2] ; arbAsk = askPx [Iask [l] , 1] * askPx [Iask [2 ] , 2] ; } else { arbBid = bidPx [Ibid [l] , 1] / askPx [Iask [2] , 2] ; arbAsk = askPx [Iask [l] , 1] / bidPx [Ibid [2 ] , 2] ; } // determine if arbitrage type 1 is present: buy arb, sell primary if(bidPx[Ibid[0] ,0] - arbAsk >= Parm.arbMinDelta) { executeArb=T; primarySide = 2; arblSide = "bid";; if(arb2Action=="same") { arb2Side = "bid";; arb2Size=askSz [Iask[2] , 2] ; } else { arb2Side = "ask"; arb2Size=bidSz [Ibid[2] , 2] ; } orderSize = Min(bidSz [Ibid[0] ,0] , askSize[Iask[l] ,1] , arb2Size, Parm.maxOrderSize) ; } // determine if arbitrage type 1 is present: sell arb, buy primary if(arbBid-askPx[Iask[0] ,0] >= Parm.arbMinDelta) { executeArb=T; primarySide = "ask"; arblSide = "ask"; if(arb2Action=="same") { arb2Side = "ask"; arb2Size=askSz [Iask[2] , 2]; } else { arb2Side = "bid"; arb2Size=bidSz [Ibid[2] , 2] ; } orderSize = Min (askSz [Iask [0] , 0] , bidSize [Ibid [l] , 1] , arb2Size) ; }
Submit Trades: needToWait = curTime - lastOrderTime <= Parm.minWaitTime if(orderList = NULL) openOrder = FALSE else openOrder = TRUE // submit a trade if we have an arb opportunity, there are no // open orders, and we don't need to wait if(executeArb && IopenOrder && !needToWait){ lastOrderTime = curTime; //submit order to primary market if(primarySide==l) submitOrder(market=Ibid[0] , type=Parm.orderType[0] , symbol=Parm.symbolPrimary, side="bid", price=askPx[Iask[0] ] +Parm.priceDelta[0] , size=OrderSize) ; else submitOrder(market=Iask[0] , type=Parm.orderType[0] ,
l-NY/1922975.1 106 symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [ O] ] -Parm. priceDelta [0] , size=OrderSize) ; //submit order to arbl market if (arblSide==l) submitOrder (market=Ibid [l] , type=Parm. orderType [1] , symbol =Parm. symbolPrimary, side="bid" price=askPx [lask [l] ] +Parm.priceDelta [l] , size=OrderSize) ; else submitOrder (market=Iask [l] , type=Parm. orderType [ 0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [l] ] -Parm.priceDelta [1] / size=OrderSize) ; //submit order to arb2 market if (arb2Side==l) submitOrder (market=Ibid [2] , type=Parm. orderType [0] , symbol =Parm. symbolPrimary, side="bid" price=askPx [Iask [2 ] ] +Parm.priceDelta [2] , size=OrderSize) ; else submitOrder (market=Iask [2] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [2] ] -Parm.priceDelta [2] , size=OrderSize) ;
Bot Specification
Subscriptions and Publications Bot8X subscribes to the following messages
• Price Feed Updates (one for each market) • Order Execution Reports (one for each market) • Bot Parameter Control Updates
Bot8X publishes the following messages:
• New Order Messages • Control Parameter Settings Report • Bot8X Activity Messages
Bot80 Bot80 subscribes and publishes to just DAR. The price feed is the DAR feed
Message Details See the spreadsheet tibFormats.xls for details of all messages. This section describes details of the messages in terms of how they are used in Bot8X.
PAR Price message
Figure imgf000135_0001
1-NY/1922975.1 107
Figure imgf000136_0001
Stack Price message
Figure imgf000136_0002
BotδX Engine
Background The Bot8X engine executes triangular-arbitrage opportunities that exist between three currencies in one or more markets.
Basics Triangular arbitrage is based on a fundamental relationship between three currencies. For example, with USD, EUR, and the JPY, we have Bid EUR/JPY » Bid EUR/USD x Bid USD/JPY Ask EUR/JPY « Ask EUR/USD x Ask USD/JPY An arbitrage opportunity arises if Bid EUR/JPY > Ask EUR/USD x Ask USD/JPY In this case, we can exploit the opportunity by selling the "primary" currency EUR/JPY and buying the "arb" currencies EUR/USD and USD/JPY. This is depicted in FIGURE 74. Similarly, we have an arbitrage opportunity if Ask EUR/JPY < Bid EUR/USD x Bid USD/JPY This situation is depicted in figure 75. FIGURE 74 illustrates a type 1 arbitrage.
1 -NY/1922975 1 108 FIGURE 75 illustrates a type 2 arbitrage.
Trading Lot Size Residual A complication in the triangular arbitrage is the constraint that we trade in fixed lot sizes. This will mean that even we execute a triangular arbitrage successfully (i.e.. all three currencies are traded), we still end up with a residual from the trade. Let
Pes = trade price for EUR/JPY Pe$ = trade price for EURAJSD P$¥ = trade price for USD/JPY
Then if we buy one million in EUR/JPY and sell one million EUPJUSD and USD/JPY, then we end up with a zero balance for EUR and JPY but a non-zero balance for USD:
USD residual = 1,000,000 x (1-1/Pe$)
The size of the residual depends on how close the EUR/USD is to parity (Pe$=l).
Multiple Markets In principle, the extension to multiple markets is straightforward. The arbitrage is based on the composite best bid and best ask for each currency pair as the best ask and best bid across all markets. Two complications arise, however, when we extend to multiple markets:
1. The tradable lot size is not the same for all markets. This makes certain markets more desirable in order to minimize the arbitrate residual. 2. The transaction cost and execution performance is not the same across all markets.
FIGURE 76 illustrates an exemplary processing flow for Bot8X. In an embodiment, if there are no open Bot8X orders, then Bot8X looks for an arbitrage opportunity.
FIGURE 77 illustrates a secondary processing flow for Bot8X.
Algorithm and Processing Flow The primary and secondary processing flows are shown in FIGRUES 76 and 77.
Parameters and Variables
Parameters Symbol Specific
Figure imgf000137_0001
1-NY/1922975.1 109 to
Figure imgf000138_0001
Figure imgf000138_0002
Internal Cache lastOrderTime = last time an order was submitted
External Cache P = number of markets askPx = P x 3 matrix of (best) ask prices from each market & currency pair askSz = P x 3 matrix of sizes at the (best) ask for each market &. currency pair bidPx = P x 3 matrix of (best) bid prices from each market & currency pair bidSz = P x 3 matrix of sizes at the (best) bid for each market & currency pair Iask = vector of length 3 giving the index of market that gives the composite best ask for each currency pair Ibid = vector of length 3 giving the index of market that gives the composite best bid for each currency pair
OrderBook orderList = list of open orders
Local Stateless Variables arbBid = arbitrage bid price arbAsk = arbitrage ask price executeArb = if TRUE, then an arb should be executed openOrder = if TRUE, then an order is open needToWait = if TRUE, need to wait before submitting a new order primarySide = side of the order for the primary currency pair arblSide = side of the order for the arbl currency pair arb2Side = side of the order for the arb2 currency pair orderSize = size of the order
Algorithm and Pseudocode
Functions: minRowlndex(double mat[] [] , long j) : returns row with the minimum value in column j maxRowlndex(double mat[] [] , long j) : returns row with the maximum value in column j submitOrder(enum market, enum orderType, enum symbol, enum side, double price, long side) : submit an order to the specified market
Arb Calculation: // index of market with composite best bid and ask For(j=0; j++; j<3) {
1 -NY/1922975.1 110 Iask.j] = minRowIndex(askPx.j) ; Ibid[j] = maxRowIndex(bidPx, j) ; } // compute arbitrage price if(arb2Action=="same"){ arbBid = bidPx[Ibid[l] ,1] * bidPx[Ibid[2] ,2] ; arbAsk = askPx[Iask[l] , 1] * askPx[Iask[2] , 2] ; } else { arbBid = bidPx[Ibid[l] , 1] / askPx[Iask[2] ,2] ; arbAsk = askPx [IaSk[I] , 1] / bidPx[Ibid[2] ,2] ; } // determine if arbitrage type 1 is present: buy arb, sell primary if(bidPx[Ibid[0] ,0] - arbAsk >= Parm.arbMinDelta){ executeArb=T; primarySide = 2; arblSide = "bid";; if(arb2Action=="same"){ arb2Side = "bid";; arb2Size=askSz[Zask[2] , 2] ; } else { arb2Side = "ask"; arb2Size=bidSz[Ibid[2] , 2] ; } orderSize = Min(bidSz [Ibid[0] , 0] , askSize [Iask[l] , 1] , arb2Size, Parm.maxOrderSize) ; } // determine if arbitrage type 1 is present: sell arb, buy primary if(arbBid-askPx[Iask[0] ,0] >= Parm.arbMinDelta) { executeArb=T; primarySide = "ask"; arblSide = "ask"; if(arb2Action=="same") { arb2Side = "ask"; arb2Size=askSz [Iask[2] , 2]; } else { arb2Side = "bid"; arb2Size=bidSz [Ibid [2] , 2] ; } orderSize = Min(askSz [Iask[0] , 0] , bidSize [Ibidtl] , 1] , arb2Size) ; }
Submit Trades: needToWait = curTime - lastOrderTime <= Parm.minWaitTime if(orderList = NULL) openOrder = FALSE else openOrder = TRUE // submit a trade if we have an arb opportunity, there are no // open orders, and we don't need to wait if(executeArb && !openOrder && 1needToWait) { lastOrderTime = curTime; //submit order to primary market if(primarySide==l) submitOrder(market=Ibid[0] , type=Parm.orderType[0] , symbol=Parm.symbolPriinary, side="bid", price=askPx[Iask[0]]+Parm.priceDelta[0] , size=OrderSize) ; else submitOrder(market=Iask[0] , type=Parm.orderType[0] , symbol=Parm.symbolPrimary, side="ask", price=bidPx[Ibid[0] ] -Parm.priceDelta[0] , size=θrderSize) ; //submit order to arbl market if(arblSide==l) submitOrder(market=Ibid[1] , type=Parm.orderType[l] , symbol=Parm.symbolPrimary, side="bid", price=askPx[Iask[1] ]+Parm.priceDelta[1] , size=θrderSize) ;
1-NY/192297-U Hl else submitOrder (market=Iask [l] , type=Parm. order-Type [0] , symbol=Parm. symbolPriinary, side="ask" , price=bidPx [Ibid [l] ] -Parm. priσeDelta [l] , size=OrderSize) ; //submit order to arb2 market if (arb2Side==l) submitOrder (market=Ibid [2] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="bid" . price=askPx [Iask [2] ] +Parm. priceDelta [2] , size=OrderSize) ; else submitOrder (itιarket=Iask [2] , type=Parm. orderType [0] , symbol=Parm. symbolPrimary, side="ask" , price=bidPx [Ibid [2] ] -Parm.priceDelta [2] , size=θrderSize) ;
Bot Specification
Subscriptions and Publications Bot8X subscribes to the following messages
• Price Feed Updates (one for each market) • Order Execution Reports (one for each market) • Bot Parameter Control Updates
Bot8X publishes the following messages:
• New Order Messages • Control Parameter Settings Report • Bot8X Activity Messages
BotSO Bot80 subscribes and publishes to just DAR. The price feed is the DAR feed
Message Details See the spreadsheet tibFormats.xls for details of all messages. This section describes details of the messages in terms of how they are used in Bot8X.
PAR Price message
Figure imgf000140_0001
1 -NY/1922975.1 112 Stack Price message
Figure imgf000141_0001
BotθO Engine
Background The Bot90 engine computes the real-time volatility. The method is based on the approach of estimating the individual volatilities using a time series model and back-out the covariances from the triangular arbitrage relationship. See [2] for methodological details.
Basic Model FIGURE 78 illustrates an embodiment of how Bot90 estimates volatility for a specified time interval Δ. In an embodiment, to ensure that the estimate is updated frequently, Bot90 can compute different estimates across P subintervals.
Let
Δ = time interval over which to compute returns (e.g., 5 minutes) nSub = number of sub-intervals to update the estimate (e.g., 5 which means a new estimate is computed every minute if Δ = 5 minutes) m = number of intervals to forecast ahead Ct - calendar factor for time t Rt = return over the interval Δ at time t ERt — return over the interval Δ at time t Zt— i.i.d. zero mean and unit variance random variable σt — estimated local volatility for time t oco, OCj, βj = GARCH model coefficients
Bot90 produces an estimate of the volatility for the current and future intervals using the following model:
R1 — ER1 = C1C1Z1
The seasonal effects are estimated ahead of time. The local volatility σt is estimated using a GARCH model applied to (R, - ER1)ZCf The forecasted volatility Vt is
1-NY/1922975.1 113
Figure imgf000142_0002
where is the forecasted local volatility given data through time t. GARCH Forecasts The GARCH(p,q) Model For a GARCH(p,q) model, we have ) ) The GARCH(1 ,1) Model For the GARCH(I5I) model, the forecast equation is
Figure imgf000142_0003
Calendar Factors The calendar factors are fixed effects modeling a variety of events:
• Time of day and day of week effect • Holidays • Asian daylight savings effect • Economic data release • Market open
These factors are multiplicative to yield a single calendar factor Ct. FIGURE 79 displays the aggregate factor for five weeks superposed on a weekly time scale. FIGURES 80 and 81 display the individual effects superposed on a twenty-four hour clock.
FIGURE 79 illustrates the Calendar effects over five weeks.
FIGURE 80 illustrates the time of day, holiday and Asian daylight savings time effects.
FIGURE 81 illustrates an economic calendar effects.
Standard Classification Coefficient Value Error t-value Intercept 0.0072 0.0116 0.6183 Daily 1 -0.6377 0.0162 -39.4137 Daily2 -0.4568 , 0.0167 -27.2756 Daily3 -0.1080 0.0166 -6.5272 Daily4 -0.0957 0.0163 -5.8825 Daily5 0.1554 0.0159 9.7695 Dailyό 0.2520 0.0163 15.4654 Daily7 -0.2102 0.0159 -13.2432 intra-day and Dailyδ -0.0808 0.0156 -5.1893 mil α wccJv Daily9 -0.0690 0.0140 -4.9439 Daily 10 -0.1328 0.0137 -9.7146 Dailyl l 0.0066 0.0139 0.4779 Dailyl2 -0.0313 0.0137 -2.2828 Dailyl3 0.0007 0.0140 0.0495 Daily 14 -0.0184 0.0136 -1.3454 Dailyl5 -0.0044 0.0139 -0.3173 Dailylό -0.0113 0.0137 -0.8228 AsiaDSTl -0.5041 0.1330 -3.7894 AsiaDST2 0.4091 0.1492 2.7416 AsiaDST3 0.0198 0.1521 0.1304 AsiaDST4 -0.1902 0.1334 -1.4251 NYCHolidayl -0.0131 0.0099 -1.3255 IN I XlOllQαy NYCHoliday2 -0.0001 0.0002 -0.4598 London EuroHolidayl -0.1513 0.0493 -3.0675 Holiday EuroHoliday2 0.0063 0.0029 2.1501 AsiaHolidayl -0.0009 0.0150 -0.0569 Tokyo Holiday AsiaHoliday2 -0.0006 0.0005 -1.1664 Table 1: Coefficients corresponding to intra-day calendars and holiday calendars.
1 -NY/1922975.1 115 Release Standard Peak Classification Coefficient Value Error t-value Effect US USEmployment 1 4.1925 0.4715 8.8912 8.1354 Employment USEmployment2 -1.4626 0.4278 -3.4189 (King Release, lasting 70 minutes) U SEmploy ment3 0.1683 0.0776 2.1698 USISMNonManf 1.3458 0.2153 6.2504 3.8264 USPhilFed 1.0795 0.2014 5.3604 2.9341 USConsConf 1.0435 0.2806 3.7192 2.8306 Category 1 USGDP 0.7494 0.2886 2.5968 2.1112 releases (lasting 0.9963 0.3492 for 40 minutes) USISMManf 2.8533 2.7005 USRtlSale 0.7461 0.3535 2.1107 2.1042 UShelpWanted 0.4758 0.2342 2.0310 1.6070 GMIFO 1.5291 0.2514 6.0818 4.5936 USChicagoPMI 2.0581 0.6504 3.1643 2.7984 USDurGoods 1.5802 0.6387 2.4740 2.2036 USPPI 1.0005 0.6932 1.4433 1.6491 USCPI 1.5745 0.4492 3.5052 2.1973 USFOMCMeet 0.7043 0.5322 1.3235 1.4221 USLeadlnd 0.9604 0.4097 2.3442 1.6164 USProdCost 0.9326 0.9766 0.9550 1.5941 USIndProdCap 1.0010 0.5311 1.8847 1.6496 USWholelnv 0.9249 0.3187 2.9024 1.5879 USTradeBal 0.5998 0.5375 1.1160 1.3497 Category 2 USPersIncome 0.8495 0.4387 1.9365 1.5292 releases (lasting for 20 minutes) USTreasBudget 1.1037 0.5032 2.1934 1.7365 EUCPIFlash 2.3536 0.0450 52.3334 3.2440 EUCPI 1.0867 0.4949 2.1960 1.7217 EUIndProdPrice 1.0355 1.3001 0.7965 1.6783 EUIndProd 2.1053 0.4126 5.1022 2.8652 EULaborCost 0.9799 0.5117 1.9150 1.6322 EUGDP 0.7295 0.6106 1.1946 1.4401 EUECBBulletin 1.2821 0.4300 2.9815 1.8984 GMCPIPre 0.9912 0.5275 1.8793 1.6415 GMCPIFn 0.6365 0.6262 1.0165 1.3747 GMGDP 0.5634 0.3978 1.4163 1.3254 Table 2: Coefficients corresponding to the economic calendar events.
Algorithm and Processing Flow FIGURE 82 illustrates an exemplary processing flow for Bot90.
Parameters and Variables
Parameters nSub = number of sub-intervals Delta = time interval over which to compute returns (Δ) nFore = number of time periods to forecast (m)
GARCH Model Parameters (from Bot91) nAlpha = number of alpha parameters (must be 1 for now)
1 -NY/1922975 1 116 nBeta = number of beta parameters (must be 1 for now) Coefs = vector of nAlpha+nBeta+1 coeffcients ((X0, (X1, P1) P = max (nAlpha, nBeta)
Seasonal Factor Parameters (from Bot92) seasFactor = vector of seasonal factors for the current and next trading weeks intervalTime = vector of times corresponding to the seasonal factors nlntervals = length of seasFactor and intervalTime
Local Variables curTime = current time curlnterval = current interval for the seasonal factors offset = offset from the beginning of the time interval FV = current fair value sigma2 = current GARCH variance subXndex = index of current subinterval lastFV = nSub vector of the last fair for each subinterval lastSigma2 = nSub vector of the last GARCH variance for each subinterval lastSublndex = index of last subinterval
Outputs ForeTimes = vector of nFore times to forecast Forecast = vector of nFore forecasted values
Functions garchForecast ( ) = computes the volatility forecast findlndex O = find an index of where a value is in a sorted list initBot O = initializes variables importSeasonalFactors ( ) = imports the seasonal factors from the database for the current and following weeks
GARCH Forecast Function The GARCH forecast function is called by a regular timer. The function first determines the current interval and sub-interval for calculations, skipping the times that fall on the weekend. It then updates the GARCH forecast variance and outputs the forecast.
// set the interval for the seasonal factor ,- FV = getFV O ; curTime = timeDateO; curlnterval = findlndex(curTime, intervalTime); // compute offset of the subinterval from the current interval offset = curTime-intervalTime[curlnterval] ; // if weekend, quit and do nothing if(offset>Delta) info("Weekend: no calculation from bot") ; // compute sub interval sublndex = Math.round(nSub*offset/Delta) if(sublndex != Math.mod(lastSublndex+l, nSub)) error("Timer out of sync with intervals"); lastSublndex = subXndex;
// compute log return logRet = (log(FV) - log(lastFV[sublndex] )))/seasFactor[curlnterval] ; lastFV[sublndex] = FV
// GARCH(I,!) 1-Step Ahead Forecast
1 -NY/1922975.1 \ \η sigma2 = Coefs C O] + Coefs ll] * logRet * logRet + Coefs [2] * lastSigma2 ; lastSigma2 [sublndex] = sigma2 ; Forecast [ 0] = sigma2 ;
// GARCH ( I , 1) nFore-Step Ahead Forecast if (nFore>l) { for ( i=l ; i<nFore ; i++) { Forecast [i] = Coefs [0] + (Coef s [1] +Coef s [2] ) *Forecast [i- 1] ; }
// Set forecast times and normalize forecasts by seasonal factor,- for(i=0; i<nFore; i++) { ForeTimes[i] = intervalTimetcurlnterval+i+l] ; Forecast [i] = Forecast[i] * seasFactor[curlnterval+i+l] ; }
Initialization & Utility Functions
initBot The initBot function is called after the first good fair value price is received.
// call out to DB to import the seasonal factors importSeasonalFactorsO ;
// initialize timer curlnterval = findIndex(curTime, intervalTime) ; offset = curTime-intervalTime[curlnterval] ; sublndex = Math.round(nSub*offset/Delta) ; startTime = intervalTime[curlnterval] +(sublndex+l) *Delta/nSub; initTimer(start=startTime, interval=Delta/nSub) ;
// initialize local variables; set lastFV to current FV // and set sigma to the "asymptotic" variance lastSublndex = sublndex; FV = getFVO; sigma2 = Coefs [0]/(1-Coefs[1] -Coefs[2] ) ; for(i=0; i<nSub; i++) { lastFV[i] = FV; lastSigma2 [i] = sigma2; }
findlndex(x, y) Find the smallest index in a sorted ascending vector x such that x[index]>y. If y is bigger than all values of x, then return -1.
Bot Specification
Inputs and Outputs Bot90 subscribes to the following messages
• Price Feed Updates • Bot Parameter Control Updates
Bot90 publishes the following messages:
1 -NY/1922975.1 U 8 • Volatility forecasts • Control Parameter Settings Report • Bot90 Warning/Error Messages
Bot90 imports the following data from a database: • Seasonal factors and the associated time intervals
BotBase Overview
A bot can be a specific application of BotBase, which is a generic application, built on top of the Java Service Container with Filter Services. The Container provides services and a set of high level interfaces to TIB connections, databases, threading and initialization from LDAP and XML. In addition, BotBase provides services and interfaces that are common to all bots. It automates grouping of Java threads that operate on a set of TIB messages filtered by symbol (e.g. EUR/USD).
FIGURE 83 illustrates an embodiment of BotBase.
BotFilter
BotFilter is the abstract super class providing common interfaces for all bot engines. It is a subclass of the ServiceContainer's Filter class helping to provide automatic grouping of Java threads that operate on a set of TIB messages filtered by symbol (e.g. EUR/USD). Each bot engine implements specific algorithms for the BOT.
The primary tasks for a BotFilter object includes 1) Initialization 2) Handling all inbound/outbound messages 3) Accessing database 4) Providing timers 5) Managing objects that perform business logic
FIGURE 84 illustrates an embodiment of a BotFilter.
Control Parameters: ParamBySymbol
Each bot has one Param object that contains a set of ParamMatrix objects. ParamMatrix is an abstract super class providing common interfaces for accessing the control parameters stored as a matrix. ParamBySymbol is a subclass of ParamMatrix providing storage of control parameters where each column is for each symbol. ParamBySymbol provides methods such as: 1) Updating its contents with an input Tib message or primitive data types. 2) Serializing to disk as a flat file. 3) Serializing to an Oracle database. 4) Constructing a Tib message filling with its contents.
l-NY/1922975.1 1 19 A bot can have control parameters dynamically controlled by Tibrv messages such as that generated by the BotControl UI. A sub class of ParamBySymbol must be created for the bot to specify the default value of the matrix data and its row names, which are the Tibrv field names. Three methods must be overridden to provide access to the default data and the Tibrv field names. For example:
public class BotDemoParamBySymbol extends ParamBySymbol { //Tibrv field names (row names). public final static String[] STR_TibrvFieldNames ={ "Symbol", "TradingOn", "Parami", "Param2"}; //Data for parameters stored as a matrix . private double data[][]= {// EURUSD, USDJPY, EURJPY, Min, Max, Type {SYM.EURUSD, SYM.USDJPY, SYM.EURJPY, SYM.MIN, SYM.MAX, TYPE.SYM}, //Symbol { BOOLF, BOOLF, BOOLF, BOOLMIN, BOOLMAX, TYPE.BOOL}, //TradingOn { 5.0, 5.0, 6.0, 0.0, 15.0, TYPE.DOUBLE}, //Parami { 5, 5, 3, 1, 20, TYPE.INTEGER}, //Param2 }; public double[][] getDataQ { return data; } public void setData(double[][] data) { this.data = data; } public String[] getTibrvFieldNames() { return STR TibrvFieldNames; } }
Each entry of the matrix, if not numeric, must be entered as numeric value provided by the appropriate class for the type specified in the last column. The class, for example SYM, provides a map from numeric values to information associated with symbols. New classes can be created and add to the system as needed.
FIGURE 85 illustrates an embodiment of a class hierarchy.
Cache
Each bot has an object of Cache class. A Cache object contains objects that manage data cached in memory. BotCache is an abstract super class providing common interfaces for accessing the cached data. The objects, contained in the Cache class, are grouping into several groups. Each group is managed by an object of classes including:
1) ExternalCache 2) InternalCache 3) OrderBook
The interfaces to a cache object include:
1) Updating its contents with an input TIB message or primitive data types. 2) Constructing a TIB message filling with its content.
l-NY/1922975.1 120 3) Specific computations on its content.
Bot Design
Fault Tolerance/Disaster Recover FIGURE 86 illustrates an embodiment with a primary and secondary instance of a Bot running on servers in physically different locations.
Fault tolerance is ensured by maintaining primary and secondary bots. If the primary bot fails, then the secondary bot becomes primary (warm start). A new secondary bot is started and initialized. If no secondary bot is running when a primary bot fails, then the primary bot must be cold started.
Cold Start of a Bot FIGURE 87 illustrates an embodiment for the initialization of a bot when a primary bot is not running.
Internal State: left uninitialized Bot41 => Order book RVCache => External state Bot41 => Market parameters DB=> Bot parameters
Maintenance of the Secondary Bot
FIGURE 88 illustrates an embodiment for the initialization and updating of state variables for the secondary bot.
Initialization of the secondary bot (no primary bot): Secondary bot left dormant until a primary becomes active
Initialization of the secondary bot (primary bot active): Primary Bot => Snapshot of current internal state of the bot Bot order book left unitialized Bot41 => Snapshot of current market parameters RVCache => Snapshot of current external market state Primary Bot => Snapshot of current bot parameters
Maintenance of the secondary bot: Primary Bot => Updates to internal state of the bot Bot order book left unitialized Bot41 => Update of current market parameters Bot 10, Bot90 => Updates to external market state
1-NY/1922975.1 121 Primary Bot => Updates to bot parameters (ctrl.out messages) Activation of the secondary bot: Bot41=> Snapshot of the bot order book Bot Activation/Deactivation Bot activation and deactivation depends on heartbeats. Let
E = External heartbeat P = Primary heartbeat Sj = Secondary heartbeat(s) I = Inactive A = Active
Primary Bot Deactivation to Secondary If (E = I & Sj = I) Then change Bot status from primary to secondary *>
If (P=A & other primary Bot has higher priority as the primary) Then change Bot status from primary to secondary
Secondary Bot Activation to Primary If (P=I & E=A & (Sj = 1 1 (Sj =A & other secondary Bots have lower priority as the primary)) Then change Bot status from secondary to primary
If (P=A & current primary Bot has lower priority as the primary) Then send primary heartbeat message
Bot priority as the primary The primary heartbeat message includes a weight W to determine the priority of the sending bot as a primary. In the case that two active primary bots (or two or more secondary bots) have the same weight, the priority is given to the bot with the
• Earlier instantiation time as a primary (or secondary) bot • Or in the case of identical instantiation times, the smaller instance ID
Bot41: Order Book Initialization FIGURE 89 illustrates an embodiment for the initialization of the order book for a cold start of a primary instance of Bot41.
The order book is imported from the persistent storage and synchronized with messages that were received subsequent to the formation of the order book.
Primary Bot41 Cold Start The order book is initialized as follows (see FIGURE 89):
1. Subscribe and queue FIX messages 2. Query the DB for active orders and the last FIX message processed 3. Update the order book from the DB with FDC messages that were not yet processed.
1-NY/1922975.1 123 Secondary Bot41 Cold Start The order book is initialized in a similar manner to the primary Bot41, except that the order book is taken from the primary Bot41 instead of the database.
1. Subscribe and queue FIX messages and order.in messages 2. Request order book snapshot from Bot41, the last FIX message processed, and the last order.in message processed 3. Update the order book from Bot41 with FIX and order.in messages that were not yet processed.
Bot Monitoring
Monitoring Class
Figure imgf000152_0001
Update Monitor Method
Arguments: ob j = monitoring object value = value being monitored
Pseudo-code: if(greaterThan) { if(value >= criticalLevel){ nCritical = nCritical+1; . if(nCritical < criticalMaxReport) issueCritical(obj, value);
} else if(value >= warnLevel) { Warn = nWarn+1; if(nWarn < warnMaxReport) issueWarning(obj, value); } else { nWarn = 0; nCritical = 0; } } else { if(value <= criticalLevel) { nCritical = nCritical+1; if(nCritical < criticalMaxReport) issueCritical(obj, value);
} else if(value <= warnLevel) { . Warn = nWarn+1; if(nWarn < warnMaxReport) issueWarning(obj, value); } else { nWarn = 0; nCritical = 0;
1-NY/1922975.1 124 }
Bot Logging
The following subjects should be captured and logged to a database/file
LEH.XFX.<stream>.INCL.MD.OUT.<symbol>.<product>.<date>.0.X LEH.EFX.MLN.TRADE LEH.MERLIN.<bot>.<symbol>.ORDER.<type> LEH.MERLIN.CTRL.<bot>.<symbol>.<type>"
A rolling history of five business days should be retained.
Bot Monitoring
FIGURE 90 illustrates an embodiment for the initialization and updating of state variables for the secondary bot at different stages in the bot life cycle: initialization, maintenance and activation of the bot.
Fault Tolerance - Secondary Bots Initialization of the Secondary Bot
Primary Bot => Internal State Primary Bot => Parameters
External State left un-initialized Order Book left un-initialized
Maintenance of the Secondary Bot Primary Bot => Internal State Primary Bot => Parameters BotlO, Bot90, ...=> External State
Order Book left blank
Activation of the Secondary Bot BotOMS => Order Book
Note: The order book could be initialized from the BotOMS and the Primary Bot. This requires a more complicated process since the secondary bot would need to synchronize information from both sources. For example, if we imported the order book from Bot41, we would need to check if any new orders were submitted from the Primary Bot but not yet processed by Bot41. By importing the order book at activation time, there is only one source for the information and no synchronization issues.
1 -NY/1922975.1 J 25 Bot Monitoring Monitorin Class
Figure imgf000154_0001
Update Monitor Method
Arguments: ob j = monitoring object value = value being monitored
Pseudo-code: if(greaterThan) { if(value >= criticalLevel){ nCritical = nCritical+1; if(nCritical < criticalMaxReport) issueCritical(obj, value);
} else if(value >= warnLevel){ Warn = nWarn+1; if(nWarn < warnMaxReport) issueWarning(obj, value); } else { nWarn = 0; nCritical = 0; } } else { if(value <= criticalLevel) { nCritical = nCritical+1; if(nCritical < criticalMaxReport) issueCritical(obj, value);
} else if(value <= warnLevel){ Warn = nWarn+1; if(nWarn < warnMaxReport) issueWarning(obj, value); } else { nWarn = 0; nCritical = 0; }
BotLogging
The following subjects should be captured and logged to a database/file
LEH.XFX.<stream>.INCL.MD.OUT.<symbol>.<product>.<date>.0.X LEH.EFX.MLN.TRADE LEH.MERLIN.<bot>.<symbol>.ORDER.<type> LEH.MERLIN.CTRL.<bot>.<symbol>.<type>"
A rolling history of five business days should be retained.
1-NY/1922975.1 126 Bot Overview FIGURE 91 illustrates a Bot Overview in the present systems and methods.
Figure imgf000155_0001
Price Engine: Bubble Filter
Background FIGURE 92 illustrates an embodiment of price filter inputs, intermediate calculations and outputs.
The broadcast is taken as fair value plus/minus the radius times a scale factor rounded to the nearest whole price:
C = 10λ-digits askBroadcastRadius = min(askBroadcastRadiusMax*C, R*askBroadcastRadiusMult + askBroadcastDelta*C) bidBroadcastRadius = min(bidBroadcastRadiusMax*C, R*bidBroadcastRadiusMult + bidBroadcastDelta*C) BroadcastAsk = round(FV + askBroadcastRadius) BroadcastBid = round(FV - bidBroadcastRadius)
FIGURE 93 illustrates an embodiment for the calculation of a radius.
1-NY/1922975.1 127 Let
Rt-1 = radius as previous tick dt = spread at tick t between the best dealable ask and bid Δt,max = RadiusMaxSpread Δt,min = RadiusMinSpread λ = radius smoothing parameter δ = delta factor to adjust radius
Then the radius at tick t is computed by
et = min(max(dt, Δt,min), Δt)maχ) , Dt-1 = 2* (Rt-1 - δ) Dt = λ Dt-i + (l-λ) et Rt = Dt/2 + δ
Inputs
PAR price message
Message Subject:
"LEH.EPARM.PRICE.FX.SPOT.<symbol>.DAR.MLN.RAW.UPDATE"
<symbol> = "EURUSD" or "EURJPY" or "USDJPY".
Message Format:
Figure imgf000156_0001
1-NY/1922975.1 128
Figure imgf000157_0001
Parameter Update Request If a parameter update message has Symbol = "ALL", then the values for the parameters in the message are updated for all symbols.
If a parameter update message has SendAll=TRUE, then the bot should broadcast all parameter values following all updates.
Message Subject "LEH.MERLIN.CTRL.BUBBLE.<column>.IN"
<column> = "ALL" | "EUR/USD" | "EUR/JPY" | "USD/JPY"
Message Format
Figure imgf000157_0002
Outputs
Price Broadcast
Message Subject: "LEH.MERLIN.PRICE.FX.SPOT.<symbol>.NORMB" <symbol> = "EURUSD" or "EURJPY" or "USDJPY"
Message Format:
Figure imgf000157_0003
1-NY/19Z2975.1 129 TimeStamp | String | format: "YYYY-MM-DD HH:MM:SS:NNN UTC" (from container)
Parameter Settings Report The bubble filter publishes its current parameter settings if a parameter update message is received. If SendAll=TRUE, then it publishes all parameters; otherwise it only publishes the parameters that were modified.
If the input parameter is not valid, then the parameter is unchanged and a report is sent with the original parameter setting.
Message Subject: parameter refresh messages : " LEH . MERLIN . CTRL . BUBBLE . < C O iumn > . OUT "
<column> = "ALL" | "EUR/USD" "EUR/JPY" I "USD/JPY"
Required Fields
Figure imgf000158_0001
Classes
bubbleFilterCache
Figure imgf000158_0002
marketPataCache
Figure imgf000158_0003
1-NY/1922975 1 130
Figure imgf000159_0001
Change Log
V1.0.1 -> V1.0.2 1. Add in price checks to reject bad records. A record is declared bad if
AskDeal-BidDeal < maxCross || BidRegular>BidDeal || AskRegular<AskDeal
where maxCross is an LDAP parameter:
EURUSD: maxCross = -.0001 USDJPY: maxCross = -0.01 EURJPY: maxCross = -0.02
2. Added a floor/ceiling for prices: broadcast price should never be inside of the dealable price. 3. Corrected hack to deal with missing regular prices - these should never fall inside of dealable prices.
V1.0.2 -> V1.0.3 1. Change defaults: bidStickDown=0, bidStickUρ=0.25 2. Undid hack to fill in missing regular prices. 3. Added bidLastRegularTime and askLastRegularTime: to cache, initCache and as arguments to updateBroadcast 4. Updated robEWMA function to handle NaN' s 5. Updated updateBroadcast to pass in additional parameters to robEWMA. 6. Updated updateBroadcast to compute bidThresh and askThresh. Added bidThresh and askThresh to the broadcast. 7. Build BubbleFilter.jar on Windows. 8. Deploy on UNIX/LINUX. 9. Write results to Oracle table
V1.0.3 -> V1.1.0 1. Update bidSpreadMax and askSpreadMax parameters based on volatility of FV. 2. Publish bid and ask broadcasts with trailing zeros; e.g., a quote for EURUSD of 0.98 should be published as "0.9800". 3. Check for InvalidFlag in the DAR feed. 4. Add to LDAP the parameters bidNAChange, bidSpreadMax, askNAChange, askSpreadMax, ccy type, bidBroadcastDelta, bidBroadcastRadiusMult, askBroadcastDelta, and askBroadcastRadiusMult. 5. Moved Yeng's jar into staging: append "STAGE" in front of message & use new staging server
1 -NY/1922975.1 131 V1.1.0 -> V1.1.1 1) Change the broadcast to go off the bubble thresholds 2) Updated initialization to avoid dependence on web-cache; cleaned up underlying code. The problem with web-cache is that we were picking up values that were not correct. Now we let the filter wait until it gets enough data to start running (we need to receive updates to dealable quotes and sizes).
V1.1.1 -> V2.0.0 1) Added timers to profile performance. 2) Move to the new Java container. 3) Add arbitrage filter estimate by using as input to bubble the better of the arbitrage price Be$ B$¥ and the raw dealable price BQ? • a) Behest = max(Be$ B$¥, Bm ) b) A^best = min(Ae$A$¥, A^) )
Control Parameters Background Control parameters are a set of parameters used to dynamically modify behaviors of a server. Sending a TIB message to the server can change these parameters: Control In message. The server sends a TIB message after it has changed values of one or more parameters: Control Out message. Control In and Control Out messages are also used to request and send other information about a server. Control In Message A Control In message is used to send commands to a server to change one or more parameters. It also used to send other commands such printing current order book, printing current cache data and send out all parameter values. Each message must include all required fields. If the message is for changing values of parameters, you can specify parameter names as TIB field names with their values as string.
Subject:
"LEH.MERLIN.CTRL.IN.LEHBOT.<server>.<symbol>"
Where <server> is a server name and <symbol> is one of supported symbols such as "EUR/USD" or "2_YEAR".
The field names and data types are as follows:
Figure imgf000160_0001
1 -NY/1922975.1 132 SenderSubED field
Value in the Sender SubID field must be one of the approved names.
UserID field
Value in the UserID field must be one of the approved user IDs.
Symbol field
Value in the Symbol field must be one of
"USD/CAD " , "EUR/USD" , "USD/JPY" , "EUR/JPY" , "USD/CHF" , "EUR/CHF" , " GBP/USD" , " 2_YEAR " , " 3_YEAR " , " 5_YEAR " , " 10_YEAR " , " 30_YEAR "
Control field
Value in the control field must be one of
Parameter Value Service Action CHANGE_ABSOLUTE Change the value of parameters as specified in other TIB fields by replacing the value with the supplied value CHANGE_RELATIVE Change the value of parameters as specified in other TIB fields by adding the supplied value to the existing value PRINT_SNAPSHOT BOT41 only PRINT_CACHE Print cache data into a string and put it in control out TIB message CLEAR_CACHE Clear or reset all cache data to default values CANCEL-ALL Cancel all open limit orders if any PRINT-MKT-PARAM Print parameters associate with market data such as futSettlDate SEND-BOT-PARAM Send all parameter values REQUEST-BOT-PARAM Same as SEND-BOT-PARAM but the response will be REPLY_BOT_PARAM REPLY-BOT-PARAM response to REQUEST-BOT-PARAM REQUEST_MKT_PARAM Ctrl In to B0T41 only: request for market parameters such as futSettlDate for LEH market REPLY-MKT-PARAM BOT41 only: reply to REQUEST-MKT-PARAM by sending market parameters REQUEST-SNAPSHOT B0T41 only: request for the order book for a trading bot REPLY-SNAPSHOT B0T41 only: reply to REQUEST-SNAPSHOT by sending the order book for a trading bot REQUEST-CACHE Request for all cache data and expect Ctrl Out as REPLY-CACHE REPLY-CACHE Reply to REQUEST-CACHE by sending all cache data.
The REQUEST-Xx and REPLY-XX that are not for B0T41 are invented for fault tolerant pairs. A secondary server never sends any Ctrl Out message. It must send a REQUEST message to the primary server.
For example: To send a control in message for changing MaxOrderSize of SERVER-I:
LEH.MERLIN.CTRL.IN.LEHBOT.SERVERjl. USD/CHF
l-NY/1922975.1 133 {MaxOrderSize="4" Control="CHANGE_ABSOLUTE" SenderSublD="ServerControl" UserlD="ybun" Symbol="USD/CHF"}
The control out message from SERVEFM:
LEH1MERLIN-CTRLOUT1LEHBOT- SERVER-LUSDZCHF { MaxOrderSize="4.0" Control="CHANGE_ABSOLUTE" SenderSublD=" SERVER_1" Symbol="USD/CHF" } Control Out Message After updating values of control parameters, a server sends a Control Out message. Also, a server sends a control out message in response to a request specified in a Control In message. Control Out messages provide up-to-date the current state of a server, especially the current values of the control parameters.
Subject:
"LEH.MERLIN.CTRL.OUT.LEHBOT.<server>.<symbol>"
where <server> is a server name and <symbol> is one of EFX or EGOV symbols such as "EUR/USD" or "2_YEAR".
The field names and data types are the same as for the Control In message, except it does not have UserlD.
CustBot Engine
Background The CustBot engine simulates order activity from customers. It subscribes to stack price feed messages and outputs new orders.
FIGURE 94 illustrates an embodiment of a CustBot.
Generate New Order Generate a new order is generated according a to Poisson process with a rate of orderRate events per second. A Poisson process has exponential waiting times, so if Δt is the waiting time until the next order, then Δt ~ Exponential(ørder.Rαte).
// set up wait - time distribution double orderRate = Conf ig . getAt (INDEX_orderRate) ; cache . waitDF = new Exponential (orderRate, RandomElement ( ) )
// generate wait time in milliseconds ; waitTime = Math . floor ( 1000*cache . waitDF . nextDouble O ) ;
For new orders, select the type of order (aggressive or passive) using a Bernoulli distribution with p=aggOrderProb. The side of the order (buy/bid or sell/ask) using a Bernoulli distribution with/?=.5 (coin flip).
1-NY/1922975.1 134 Generate Size The order size is generated from a discrete size distribution. The size distribution is based on exponential distribution with scale parameter scaleSize, and is truncated so that the maximum order size is mctxOrderSize.
Il set up size distribution double orderSizeScale Conf ig.getAt (INDEX_orderSizeScale) ; cache. sizeDF = new Exponential (1/orderSizeScale, RandomElement () )
// generate order size,- double maxOrderSize Config.getAt (INDEX_maxθrderSize) ; size = Math. min (Math, floor (cache. sizeDF. nextDouble O ), maxOrderSize) ;
Generate Passive Order Price A passive price is generated as a random deviation <!> from current best price where δ ~ BxponcntialipassivePriceScale). If the order is a bid, then price = round(bidPrice-δ, digits); otherwise if the order is an offer, then price = round(askPrice+δ, digits).
The function round(x, digits) rounds x to a specified number of signification digits (so we are rounding prices to basis points).
// set up passive price distribution double passivePriceScale Config.getAt (INDEX_passivePriceScale) ; cache.passiveDF = new Exponential (1/passivePriceScale, RandomElement ())
// generate passive price,- C = Math. pow( 10.0, - Conf ig.getAt (INDEX_digits) ); delta = roundToDigits (cache.passiveDF. nextDouble () *C) ; if(isBid) price = bidPrice - delta; else price = askPrice+delta;
Generate Aggressive Order Price An aggressive price is generated as a random deviation θ from current best price where θ~ Uniform(0, spread + aggOrderDelta). If the order is a bid, then price = round(FF+#, digits); otherwise if the order is an offer, then price =
Figure imgf000163_0001
digits).
// generate aggressive price delta DF cache. aggDF = new uniform(RandomElement () )
// generate aggressive price double aggPriceMaxDelta = Conf ig.getAt (INDEX_aggPriceMaxDelta) ; double C = Math.pow(10.0, - Conf ig.getAt (INDEX_digits) ) ; double spread = Math.max(0.0, askPrice - bidPrice); delta = roundToDigits ( (spread + aggPriceMaxDelta) *cache . aggDF . nextDouble ( ) *C) ; if(isBid) price = bidPrice - delta; else price = askPrice+delta;
l-NY/1922975.1 135 Inputs
PAR price feed messages Message Subject: tibrvlisten -service "8938" -network ";239.191.89.38" -daemon '" "LEH.EFX.MLN.MD.OUT.* .X"
Messa e Format:
Figure imgf000164_0001
Settlement Date Message Message Subject: tibrvlisten -service "8938" -network ",-239.191.89.38" -daemon "" "LEH.EFX.MLN.SETTLE.OUT.<symbol>"
Re uire Fields:
Figure imgf000164_0002
Outputs
Stack New Order Message Message Subject tibrvlisten -service "8938" -network ",-239.191.89.38" -daemon "LEH.EFX.MLN.DEALS.IN.LEHMAN.CUSTBOTl.D"
Figure imgf000164_0003
1-NY/1922975.1 136
Figure imgf000165_0001
Classes CustBotParameters
Figure imgf000165_0002
CustBotCache
Figure imgf000165_0003
Engines CustBotManager Subscribes to: Stack Price Message Settlement Date Service
1-NY/1922975.1 137 Publishes: • Stack New Order Message
Data Filters
Data Types The following types data need to be filtered:
Figure imgf000166_0001
Figure imgf000166_0002
Process Flow
FIGURE 95 an embodiment, the output from the OCR engine is passed through some filters to form the quote data and to flag suspicious values. In an embodiment, the dealable quotes, market best quotes and the regular quotes are processed in order. New quotes can be published separately.
FIGURE 96 illustrates an embodiment of the processing flow for a quote. In an embodiment, the output from the OCR engine is use to form the price and size (if available). In an embodiment, new quotes, defined as quotes that have a new price or size, are filtered for
1 -NY/1922975.1 138 outlier or digit errors. Suspicious quotes can be held for one (or more) processing cycles to assess the validity of the quote.
Constructing the Price and Size from OCR
FIGURE 97 illustrates an embodiment of the processing flow to construct a price from the OCR.
FIGURE 97 shows the processing steps in constructing a price from the output of the OCR engine. The big figure is tied to the dealable quote. When the big figure is in transition, the market best and regular quotes sometimes need to be adjusted. The decision on when to adjust is based on keeping the proper ranking of the market best, dealable and regular quotes...
If (Bra,t<Bd,t) B-,,t = Bm,t + 100 pips If (Br,t>Bd,t) Br,t = Br,t - 100 pips If (-Vt>Ad,t> An,t = K,t ~ 100 pips If (Ar,t<Ad,t) A1.,t = -Vt + 100 pips
The size is output by the OCR and as a number. Blank sizes should be mapped to the regular size (15 for EURUSD and USDJPY and 10 for EURJPY).
Scoring Outliers
Let
C1 = large outlier relative threshold (default value is 5) C2 = moderate outlier relative threshold (default value is 3) xt = current price (one of Bn,fc, Bd/t, Br,t/ An,^, Aa,t, or Ar,t) xt-i = last "good" price (price not flagged as a possible outlier) Δt = return = xt - xt-1 σt = estimated standard deviation
A large outlier is flagged if
= CIσl_I
A moderate outlier is flagged if
= C2σM
The standard deviation σt is taken from the following table:
Figure imgf000167_0001
1-NY/1922975.1 139
Figure imgf000168_0002
Peak hours are defined as 06:00 GMT to 16:00 GMT.
Scoring Digit Errors A digit error is caused when the OCR engine scans a pair of digits during a transition from one pair to another. In the transition, the changed is captured for only one of the digit pair. For example, ..
Digit Errors - Definitions
Figure imgf000168_0001
Possible Digit Errors A possible digit error is flagged if edir,digit,t is true for any dir and digit. Confirmed Digit Errors
A confirmed digit error is flagged in the following cases:
Tens digit goes down; ones digit then goes up: ed,2 t && Eu,1#t+1
Tens digit goes up; ones digit then goes down: eu,2(t && Ed,i,t+i
Ones digit goes down; tens digit then goes up: ed( 1,t && Eu,2,t+i
Ones digit goes up; tens digit then goes down: eU/1#t && Ed,2,t+i
where t is the time of the suspended record.
Processing Suspended Records
In processing suspended records, we use information from quotes that happen after the suspended record to update the validity score of the suspended record. We are checking for completion of a possible digit error (see section 2.3).
A suspended record which is followed within 2 seconds by a record which confirms a digit error is not published. A suspended record followed by any other valid record is published.
Suspended records are unconditionally published after 2 seconds.
The older of two suspended records in a row will be published, noting that there is a possible digit error.
Future versions will try to identify market shifts versus isolated bad ticks (outliers).
Testing to Suspend a Record
We suspend the publication of a quote whenever the quote is suspicious and want to wait until more information is available (the next quote). In the current version, we suspend quotes only when we have a moderate outlier with a possible digit error.
Future versions will suspend moderate outliers without digit errors to identify market shifts versus isolated bad ticks.
Pseudo-Code
Subjects Raw prices are nominally sent on subject X. Normalized prices are sent on subject X.NORM Filtered prices are sent on subject X.UPDATE
Entities A price X consists of the following entities:
1 -NY/1922975.1 \/\\ Px = Price Vx = Validity Cx = Changed Ex = Digit Error Ox = Outlier Flag
A size X consists of the following entities: Sx = Size Wx = Validity
A double price block D consists of the following entities: Ppjk == Price Vϋjk = Price Validity Cϋjk = Changed Flag Oπjk = Outlier Flag Eϋjk = Digit Error Flag Sok = Size WDk = Size Validity MD = Master Validity
Where
j = D (dealable), B (best), R (regular) k = B (bid), A (ask)
The Last Full Published Raw Double Price Block shall be called L. The Accumulated Good Cached Double Price Block shall be called A. The Current Double Price Block shall be called D. The Queued Double Price Blocks shall be called Q[i]. The number of elements in the queue shall be called n. i shall go from 0 to n-1.
Validities are Valid, Invalid and Missing.
Configurations Each currency pair carries the following information: • Digits after decimal point = α • Minimum price = μ • Sigma of dealable price during peak hours σop • Sigma of dealable price during off-peak hours σoo • Sigma of best price during peak hours σsp • Sigma of best price during off-peak hours σβo • Sigma of regular price during peak hours ORP • Sigma of regular price during off-peak hours σRo
OCR Validation The following numbers must be present and in the right color: • Big Figures (bid/ask) - must be black • Best Pips (bid/ask) - must be red
1 -NY/1922975.1 142 • Dealable Pips (bid/ask) - must be white or yellow
The following numbers must be in the right color: • Size (bid/ask) - must be black • Regular Pips (bid/ask) - must be yellow
Price Conversion The following tasks are performed for each side k: 1. Dealable Price PDDk = (Big Figure^ & (Dealable Pips)k. 2. IfPDDk has the wrong number of digits after the decimal point, the process is aborted and an error is published. 3. IfPDDk < μ, the process is aborted and an error is published. 4. Otherwise VøDk = Valid. 5. If Size is not present, Wok = Missing. 6. If Size is not all digits, Wok = Invalid. 7. Otherwise SDk = Size, WDk = Valid. 8. PDBk = (Big Figure)k & (Best Pips)k. 9. If PoBk has the wrong number of digits after the decimal point, VoBk = Invalid. 10. If PoBk is worse than PoDk ("worse than" = "less than" for bid, "greater than" for ask), PDBk ±= 102-α. 11. IfPDBk < μ, VoBk - Invalid. 12. Otherwise, PDRk = Valid. 13. If Regular Pips is not present, VoRk =γ Missing. 14. Otherwise, if Regular Pips is not two digits, VoRk = Invalid. 15. PDRk = (Big Figure) & (Regular Pips) 16. If PoRk has the wrong number of digits after the decimal point, VDRk = Invalid. 17. If PoDk is worse than PDRk ("worse than" = "less than" for bid, "greater than" for ask), PDRk ±= 102-α. 18. IfPDRk < μ, VDRk = Invalid. 19. Otherwise VDRk = Valid.
Setting Changed Flags If Ppjk ≠ Pijk or VDjk ≠ VLjk, then CDjk = true. If SDk ≠ SLk or WDk ≠ WLk, then CDDk = true.
Setting Error Flags 1. If Vojk = Valid and Vyk = Valid, then r = |Pojk - Pijkl / σjt where t is the time of day (peak/off-peak) 2. If r < 3, ODjk = None 3. If r > 3 and r < 5, ODjk = Moderate 4. If r > 5, Oojk = Large and MD = Invalid 5. dijk = OnesDigit(PDjk) - OnesDigit(PLjk) 6. d2jk = TensDigit(PDjk) - TensDigit(PLjk) 7. If dijk = 0 and d2jk = - 1 , -2, 8 or 9, EDjk = TensDown. 8. If dijk = 0 and d2jk = 1, 2, -8 or -9, EDjk = TensUp. 9. If d2jk = 0 and dijk > 6, Eojk = OnesUp.
1-NY/1922975.1 143
Figure imgf000172_0003
Raw / Normalized Price Publishing
Figure imgf000172_0002
Queue Evaluation as 0. "N/A".
Figure imgf000172_0001
Open Issues/Extensions
1. Reset the filters if no price is scanned for a fixed period of time (set default of 15 minutes). This avoids the problem of scanning outages due to screen saver issues. 1. Add CHF/USD and CHF/EUR 2. Add soft rules for adjusting market best and regular prices relative to the big digit. The problem is that if the dealable price has a digit error, the simple adjustment rule will create very big outliers in the other prices, spoiling the whole record. 3. Investigate leakage of isolated digit errors through existing filter. 4. Change the outlier and digit error flags to indicate which fields have errors. 5. Publish outliers and digit errors with flags so we can log in the DB. 6. Perform a final check on quote price order: dealable vs. market vs. regular and cross- market checks. 7. Improve outlier filter to work off of fair-value instead of last good price (specs to be provided by AGB). 8. Publish suspended records after 2 seconds. 9. Add in rules to deal with a big digit error. For example: 118.99 -> 118.00 -> 119.00 or 118.99 -> 119.99 -> 119.00. 10. Improve OCR rules to distinguish between blank fields and invalid fields.
Change Log
From V0.01 to V0.02:
• cleaned up definition outlier filter
From V0.02 to V0.03:
• revised processing flow diagram: main change is to publish quotes, not records • tightened definition of a digit error
From V0.03 to V0.04:
• added a simple outlier filter based on peak/off-peak thresholds • updated flow diagram • added a message type
From V0.04 to V0.05:
• refined digit error definitions • added markings for implemented / unimplemented features
From V0.05 to V0.06:
• added pseudo-code • added issues/problems section
1-NY/1922975.1 145 Subjects Raw prices are nominally sent on subject X. Normalized prices are sent on subject X.NORM Filtered prices are sent on subject X.UPDATE
Entities A price X consists of the following entities: Px = Price Vx = Validity Cx = Changed Ex = Digit Error Ox = Outlier Flag
A size X consists of the following entities: Sx = Size Wx = Validity
A double price block D consists of the following entities: Pojk = Price Vojk = Price Validity Cpjk = Changed Flag ODjk = Outlier Flag Eϋjk = Digit Error Flag SDk = Size WDk = Size Validity MD = Master Validity
Where
j = D (dealable), B (best), R (regular) k = B (bid), A (ask)
The Last Full Published Raw Double Price Block shall be called L. The Accumulated Good Cached Double Price Block shall be called A. The Current Double Price Block shall be called D. The Queued Double Price Blocks shall be called Q[i]. The number of elements in the queue shall be called n. i shall go from 0 to n-1.
Validities are Valid, Invalid and Missing.
Configurations Each currency pair carries the following information: • Digits after decimal point = α • Minimum price = μ • Sigma of dealable price during peak hours σπp • Sigma of dealable price during off-peak hours αpo • Sigma of best price during peak hours OBP • Sigma of best price during off-peak hours OBO • Sigma of regular price during peak hours σm>
1 -NY/19212975.1 146 • Sigma of regular price during off-peak hours σRo
OCR Validation The following numbers must be present and in the right color: • Big Figures (bid/ask) - must be black • Best Pips (bid/ask) - must be red • Dealable Pips (bid/ask) - must be white or yellow
The following numbers must be in the right color: • Size (bid/ask) - must be black • Regular Pips (bid/ask) - must be yellow
Price Conversion The following tasks are performed for each side k: 20. Dealable Price PDDk = (Big Figure)k & (Dealable Pips)k. 21. IfPDDk has the wrong number of digits after the decimal point, the process is aborted and an error is published. 22. If PDDIC < μ> the process is aborted and an error is published. 23. Otherwise VDDk = Valid. 24. If Size is not present, Wok = Missing. 25. If Size is not all digits, Wok = Invalid. 26. Otherwise SDk = Size, WDk = Valid. 27. PDBk = (Big Figure)k & (Best Pips)k. 28. IfPDBk has the wrong number of digits after the decimal point, Voβk = Invalid. 29. IfPDBk is worse than PDDk ("worse than" = "less than" for bid, "greater than" for ask), pDBk ±= io2-α. 30. If PDBk < μ, VDBk = Invalid. 31. Otherwise, PoRk = Valid. 32. If Regular Pips is not present, VoRk = Missing. 33. Otherwise, if Regular Pips is not two digits, VoRk = Invalid. 34. P0Rk = (Big Figure) & (Regular Pips) 35. If PoRk has the wrong number of digits after the decimal point, VDIUC = Invalid. 36. than PDRIC ("worse than" = "less than" for bid, "greater than" for ask),
Figure imgf000175_0001
37. If PDRk < μ, V0Rk = Invalid. 38. Otherwise VDI^ = Valid.
Setting Changed Flags If Pϋjk ≠ Pijk or VDjk ≠ VLjk, then CDjk = true. If SDk ≠ SLk or WDk ≠ WLk, then CDDk = true.
Setting Error Flags 13. If VDjk = Valid and VLjk = Valid, then r = |PDjk - Pijkl / σjt where t is the time of day (peak/off-peak) 14. Ifr < 3, ODjk = None 15. If r > 3 and r < 5, ODjk = Moderate 16. If r > 5, Oojk = Large and MD = Invalid 17. dijk = OnesDigit(PDjk) - OnesDigit(PLjk) 18. d2jk = TensDigit(PDjk) - TensDigit(PLjk)
l-NY/1922975.1 147
Figure imgf000176_0003
Raw / Normalized Price Publishing
Figure imgf000176_0002
Queue Evaluation and d]jk and and
Figure imgf000176_0001
1 -NY/1922975 1 148 Extension to the DAR Deals Feed
Background
The deals from the DAR feed do not report trade sizes. Moreover, the deals are only broadcast at every [x] seconds (time slice). This means that the DAR feed collects all orders that have occurred in a [x] second interval and then selects just one Buy and one Sell order to broadcast.
For each time slice, the DAR feed will broadcast the worst price among all orders received during that time slice. For example, assume 3 sell orders were executed within a time slice:
• Sell 10 at 172.50 • Sell 5 at 172.49 . Sell 5 at 172.48
Then the hit record would broadcast as 172.48 Given.
The extension to the DAR deals feed attempts to recreate the unobserved trade sizes. It takes as input the raw DAR deals feed along with a stream of possible deals/cancels derived from the raw price stream. Deals filtering involves three basic steps:
1. Filtering the DAR price stream to produce a stream of possible deals/cancels. 2. Matching the DAR hits to the stream of possible deals/cancels. 3. Scooping up unmatched deals (tentatively labeled as cancel in the 1st pass) and matching these to hits.
The output of the filter is change in reported deals and top-of-book cancels for the past τ seconds.
Filtering Deal/Cancel Records
FIGURE 98 illustrates an embodiment of the flow for a deal filter.
Let
Bo = previous dealable best bid price Bi = current dealable best bid price βo = previous market best bid price βi = current market best bid price Xo = previous size at dealable best bid Xi = current size at dealable best bid
Then output a deal/cancel record if
Bi < B0 I ) Pi < β0 | ] (Xi < Xo && Bi = B0)
The price and size of the deal/cancel is computed as follows
1-NY/1922975.1 149 if ( βx < β0 && B1 >= B0) { price = β0 ; size = NA; } else i f (B1 < B0) { price = B0 ; size = X0 ; } else { price = B1; size = X0 - X1 ;
Matching Hits Let δ = the maximum time span to classify a match as "priority" Δ = the maximum time span to match an order τ0 = start of the analysis period possible = (B0, Xo / S0) / ..., (BM, XM, SM) = price, size and time of possible deals/cancels since τo-Δ in ascending time order (so Sj < Sj+i) actual = (H0, T0) , .../ (HN/ TN) = price and time of reported hits since τ0. Xc = maximum dealable size over the interval [TN- δ, TN] Bc = current dealable price
Match Types The hits are matched to deals/cancels of the same price. A hit is classified into one of five types:
Case 1 : Priority Match FIGURE 99 illustrates an embodiment of a priority match.
A hit is classified as a priority match if it can be matched with a unmatched possible deal within the "priority interval" defined as [TN-δ, TN] . If more than one possible deals can be matched within the interval, then it is matched to the greatest time lag within the priority interval.
Case 2: Hidden Match If the hit does not have a priority match, but if at any time during priority interval [TN- δ, TN] , the dealable size exceeds 14 million (Xc>15) and the dealable price equals the hit price (Bc= HN), then the hit is classified as a "hidden" match. Since the dealable size exceeds the maximum shown, a trade that occurs at that price will not appear in the possible deals/cancels stream.
Case 3: Shift Match FIGURE 100 illustrates an embodiment of a shift match.
If a hit can't be matched to a possible deal without crossing another deal that has already been matched, and it doesn't meet the conditions for a hidden match, then the matches are
l-NY/1922975.1 150 shifted until all hits can be matched. In the above picture, matches for two hits need to be reassigned in order to match all hits.
FIGURE 101 illustrates an embodiment of an unmatched deal.
In some cases, there are no available deals to match. This can happen if there are more hits than possible deals (and the size shown is less than 15 million), or it can happen if the matches exceed the acceptable match delay time Δ. In these cases, one of the deals must be unmatched. In the above picture, the 3rd most recent deal is unmatched because it has the longest lag between possible matches.
Case 4: Delay Match FIGURE 102 illustrates an embodiment of a nearest match.
If a hit isn't matched under the conditions in cases 1-3, then it is matched to the nearest unmatched deal as in the above figure. This is classified as a delay match since it falls outside of the priority interval.
Case 5: Unmatched If a hit can't be matched under the conditions listed for cases 1-4, then it is left unmatched. This will happen if there is no deal to match within the acceptable time period or if there are no deals.
Matching Pseudo-Code
At a price P, assume that there are n reported hits and m reported deals/cancels. The following function matches the hits with the possible deals/cancels at a price:
matchAtPrice = function (possible, actual , Xc, δ, Δ) { // matches hold the index of the matching deal to the hit; -1 means // there is no match long matches[n] ; // matchType is the type of match: PRIORITY, HIDDEN, SHIFT, DELAY, or // NOMATCH enum matchType[n] ;
for(i=0; i<n; i++) { matches [i] = -1; matchType[i] = NA; } for(i=0; i<n; i++) {
// get indexes of priority matches; a priority match can't displace // an existing match (see below for the function possibleMatch) j=0; bestMatch=-l; while(Ti>Sj && j<m){ if(Ti-S.j<Δ) bestMatch = j; if(Ti-Sj<δ && j>max(matches) ){
1-NY/1922975.1 151 priority=TRUE; break; }
} if(priority) { // test for a priority match matches[i] = bestMatch; matchType[i] = "PRIORITY"; } else if(Xc >= 15) { // test for a "hidden match" when we are showing 15 million matchType[i] = "HIDDEN"; matches[i] = matches[i-1] ; } else if(bestMatch>=0 && bestMatch<=max(matches) && matchType[i-1] I="ϋHMΛTCH") { // a match is available, but would cross an existing match; // match to the nearest time and reallocate the other matches; nShift = 0; g = matches[i] = matches[i-1] ; if(T1 - S9 < δ) matchType[i] = "PRIORITY"; else matchType[i] = "DELAY"; k=i; // icompute the number of positions we need to shift the matches while(k>0 && matches[k-1] -1>-1 &&. ( (matches[k] -matches[k-1] ) <= 1) { g = matches[k-1] -1,- worstl = -1; if(matchType[k-1] !="HIDDEN" && ((g<0) I I (Tfc-1-Sg)>Δ I I (k>l && matches[k-2]==0 && g==max(matches[0: (k- 2)])))){ // if the shift would cause a large delay in a matched trade // (or if we don't have enough deals to match against) , // then un-match the worst matching trade,- worstTime = -1; for(h=k-l; h<i; h++) { g = matches[h] ; delay = Th-Sg; if(delay>worstTime) { worstTime = delay; worstl = h; } nShift = i-worstl; break; } else { k=k-l; nShift = nShift+1; } // shift the matches if(nShift>=l) { for(j=i-nShift; j<i-l; j++) { matchestj] = matches [j-1] ; matchType[j] = "SHIFT"; } // if needed, un-match the worst match
1 -NY/1922975.1 152 if(worstl>=0){ matches[i-nShift] = -1; iαatchType[i-nShift] = "UNMATCH"; } } else if(bestMatch>=0) { // match to the next best record matches[i] = bestMatch; matσhType.i] = "DELAY"; } else matchType.i] = "UNMATCH"; }
// set the price, size, reported time and actual time of the matched // trades nMatch = 0; for(i=0; i<n; i++) { price[i] = H1; reportedTime[i] = T1; j = matches [i] ; if(j>-l){ nMatch++; size[i] = XJ; actualTime[i] = S1; }
// set the index of cancelled orders nCancel = m-nMatch+1; if(nCancel>0){ cancellndex = integer(nCancel) ; k=0; j=0; for(i=0; i<n; i++) { if(matches[i]>-l){ while(j<matches[i] ) { cancellndex[k] = j;
k++; } j++; }
} return(price, size, reportedTime, actualTime, cancellndex) }
Scooping Cancels Because multiple deals can be reported in a single hit record, a 2nd pass is taken to match (scoop) cancelled orders to hits. Let
γ = maximum time lag to match a cancelled order Sj = time of jth cancelled order Bj = price of jth cancelled order Ri = reported time of the ith hit. Ti = actual time of the ith hit Bi = price of i"1 hit
1-NY/1922975.1 153 If the jΛ cancelled order occurs within γ of the reported time for the ith hit but after the reported time of the i-lst hit, then the j* cancelled order is matched to the i* hit:
max (Ri. i, Rt - γ) < Sj < Ri
Since the hit price is the worst price of all trades reported as part of the hit, cancelled orders with a price equal to or greater can be matched to the hit (Bj > Bi). If a cancelled order matches more than one hit, the order is matched to the reported hit closest in time.
Example
A sample analysis is performed on a half hour segment of data. The input and output of the analysis is given in the following spreadsheets:
darPriceIn.xls: input price stream darDealIn.xls: input deals stream darPossible.xls: output possible deals/cancel stream darMatchO.xls: output matches after applying the match algorithm darCancelO.xls: output cancels after applying the match algorithm darMatchl .xls: output matches after applying the scooping algorithm darCancell.xls: output cancels after applying the scooping algorithm
GridViewer Client
Background
FIGURE 103 illustrates an embodiment of the flow for the gridViewer client.
The gridViewer client serves two purposes:
• view the parameters for the Bots • update the parameters for the Bots
The client inputs parameter values from the bots and other devices (e.g. game pad). Parameter values that are edited in the grid views are broadcast in a message.
The parameters are displayed in a grid with the parameters along the rows and symbol along the column.
Bot10 ALL EUR/USD USD/JPY EUR/JPY MIN MAX Parameter 1 value value value value value value Parameter 2 value value value value value value
Parameter K value value value value value value
The parameter for different engines are displayed on different pages.
1 -NY/1922975.1 154 Inputs
Parameter Value/Snapshot Each engine publishes its current parameter settings. These are used to initialize and to refresh the values in the parameter grids.
Message Subject: "LEH.MERLIN.CTRL.<bot>.<column>.OUT"
<bot> = "BOTlO" I "BOT20" I "BOT30" | ... <column> = "ALL" | "EUR/USD" | "EUR/JPY" | "USD/JPY"
Required Fields
Figure imgf000183_0002
Outputs
Parameter Refresh Request The client can request for a refresh of all parameter values in a grid, including the parameter type.
Message Subject: "LEH.MERLIN.CTRL.<bot>.ALL.IN" <bot> = "BOTlO" I "BOT20" I "BOT30" | ...
Required Fields
Figure imgf000183_0003
Parameter Update If the user edits a cell in the grid view, the updated parameter value is broadcast.
The engine will respond with an parameter value message; if the parameter is invalid, the original value in the message will be republished so that gridViewer can correct its grid.
Message Subject: "LEH.MERLIN.CTRL.<bot>.<column>.IN" <bot> = "BOTl0" I "BOT20" I "BOT30" | ... <column> = ""ALL" I "EUR/USD" I "EUR/JPY
Figure imgf000183_0001
USD/JPY"
1 -NY/1922975.1 155 Required Fields
Figure imgf000184_0001
GridViewer Parameters
Figure imgf000184_0002
ManualTrader Engine
Background
FIGURE 104 illustrates an embodiment of the flow for the the ManualTrader engine.
The ManualTrader manages the stacks for manual trades submitted from the game pad and other devices. The engine receives top of stack cancel messages from gamePadTrader, identifies which orders to cancel out of the stacks and sends an cancel order message to the appropriate stack.
The ManualTrader engine has no parameters. Parameters for manual trading are primarily contained in the GamePadTrader engine.
Inputs
Stack Execution Report
Message Subject: "LEH.EFX.MLN.DEALS.OUT.FILL.LEHMAN.MANUALl.8"
Required Fields
Figure imgf000184_0003
1 -NY/1922975.1 156
Figure imgf000185_0001
PAR Execution Report
Message Subject: "Appia.MERLIN_FX.OUT.LEH_EFX.8'
Re uired Fields
Figure imgf000185_0002
Cancel Top of Stack Message
Message Subject "LEH.MERLIN.<exchange>.MANUALl.<symbol>.CANCELTOP" <exchange> = "DAR" | "STACK" <symbol> = "EUR/USD" | "EUR/JPY" | "USD/JPY" | "ALL"
Required Fields
Figure imgf000185_0003
Outputs
PAR Cancel Order Message Message Subject: "Appia . MERLIN_FX . IN . LEH-EPX . D"
Message Format:
Figure imgf000185_0004
1 -NY/1922975.1 157
Figure imgf000186_0001
Stack Cancel Order Message Message Subject "LEH.EFX.MLN.DEALS.IN.LEHMAN.MANUALl.F" Message Format:
Figure imgf000186_0002
ManualTrader Activity Message Message Subject "LEH.MERLIN.MANUALTRADER.INFO.<exchange>.<symbol>.ACTIVITY" <exchange> = "DAR" | "STACK" <symbol> = "EUR/USD" | "EUR/JPY" | "USD/JPY" | "ALL"
Figure imgf000186_0003
l-NY/1922975.1 158 Action I Number | l="Cancelled Top" | 2="Cancelled Stack" | 3="Stack Empty"
Classes
PAR Open Order Cache
Figure imgf000187_0001
Engines
ManualTrader
Subscribes to: • Stack Execution Report • DAR Execution Report • Cancel top-of-stack request
Publishes: • DAR Cancel Order • Stack Cancel Order • ManualTrader Activity Report
1 -NY/1922975.1 159 Merlin Price Cleaning
1. Symbols
A price/size is denoted as
XY
Where
X is the type: D = dealable, B = best, R = regular, S = size, X = any, P = any price (not size) Y is the side: B = bid, A = ask, Y = any
The group ("price block") of all six prices and two sizes is called W.
The following states are allowed for every price/size:
0 = Unset U = Unreadable M = Missing 1 = Invalid V = Valid E = Vacant Z = Any
The state of a price is denoted SXY. The time of a price is denoted TXY. Errors on prices are denoted EXY. Digit errors are denoted DXY. The state of a price block is shown as the concatenation of the states in the price block in this order:
SDB SSB SBB SRB SDA SSASBA SRA
Prices are cached in two caches: Raw cache (RXY, RSXY, RTXY) and Seared Cache (UXY, USXY, UTXY). The state of all caches is M upon startup.
2. Process 2.1. Market Parsing
When prices are scanned, they may be invalid or not present.
Dealable price is scanned first. If invalid or not present, SDY = U, else SDY = V. Size is scanned. If missing, SSY = M. If invalid, SSY = U, else SSY = V. If SSY = U, then SDY = U. This prevents the dealable price from changing without knowing the corresponding size change. If SDY != V, then SBY = SDY and SRY = SDY. No price is valid without the dealable price, because associating a price with the big figure requires the dealable price. Otherwise, SBY = V if best price is present and valid, U if not; SRY = V is regular price is present and valid, M if not present, U if invalid.
1 -NY/1922975.1 160 So at the end of this, each half of the price block could have the following states:
V {VM} {VU} {VMU} U U U U
2.2. Flag-checking
If SDY = U and RSDY = V, then DY = RDY. If SDY = U and RSDY != V, then SDY = M. If SDY = M, then DY = O. If SDY = M, then SSY = M and SSY = 0.
If SDY = M, then SBY = M and SRY = M.
If SBY = U and RSBY = V, then BY = RBY. If SBY = U and RSBY != V, then SBY = M. If SBY = M, then BY = O.
If SRY = U and RSRY = V, then RY = RRY. If SRY = U and RSRY != V, then SRY = M. If SRY = M, then RY = O.
So at this point each half of the price block could have the following states:
V {VM} {VM} {VM} M M M M
If SW = M M M M M M M M then stop all checking here - the panel is invalid.
2.3. Nominalizing prices
If SPY = M then skip all other steps. If "Check Best" option is off (M2 only), and P = B, skip all other steps. IfBB < DB then SBB = I and EBB += OrderError If RB > DB then SRB = I and ERB += OrderError If BA > DB then SBA = I and EBA += OrderError If RA < DB then SRA = I and ERA += OrderError
2.4. Checking for crosses
If SPB = M or SPA = M then skip all other steps. IfPA - PB < -crossedPriceThreshhold, then SPA = I, EPB += CrossError, EPA += CrossError
2.5. Push
W is pushed onto the queue. The following steps are done for all queued prices.
2.6. Check digit errors
1 -NY/1922975.1 \β\ If type PY is not suspended: If Now - TPY <= MaxSuspendedTime and a possible digit error is detected (1) with respect to UPY then a DPY is marked appropriately.
2.7. Check outlier errors
If SPY = M or USPY != V then skip this If Now - TPY > MaxOutlierTime then skip this. If I PY - UPY I > LargeOutlierRatio * Sigma[P] then EPY += LargeOutlier and SPY = I. Else if I PY - UPY | > ModerateOutlierRatio * Sigma[P] then EPY += ModerateOutlier
2.8. Attempt to confirm digit errors
If SPY != V then skip this. For each price of the same type PY in the queue after this price: If the future state is not I and there is no digit error with respect to UPY, then a. If the future state is M or the digit error is confirmed (2) with respect to PY, then SPY = I, and stop the loop. b. But, if the digit error is denied, then stop the loop.
If no suitable future price was found (ie, the loop was not stopped) then suspend type PY.
2.9. Publish
If type PY is suspended or SPY = E, publish UPY. (IfUSPY = I, see SPY=I rules below for how it will be published.) Skip the rest.
If SPY = I then: IfUSPY != M then publish UPY (and USY with UDY). Publish a separate message with invalid flag = 1 (all subsequent invalid prices for this W will also go into this message), and publish PY into it (and DY with SY).
If SPY != I then: If SPY != M then publish PY (and SY with DY). UPY = PY USPY = SPY
Publish EPY into the valid message if SPY != I, invalid message if SPY = I.
SPY = E
2.10. Unsuspend max-suspended records asynchronously
Every 100 ms run 2.6 - 2.9. (Otherwise 2.6 is only done when a new price comes in.)
1-NY/1922975.1 162 Risk Tools Risk-Price Profile
Price LehBotSize LehCJCSize DarBotSize DarCJCSize 1.0832 3 0 -3 0 1.0833 0 0 0 0 1.0834 0 0 0 0 1.0835 2 0 -1 0 1.0836 1 0 -1 -1
Figure imgf000191_0001
1.0839 3 1 -4 0 1.0840 8 0 -5 -3 1.0841 2 0 -2 0 1.0842 0 0 0 0 1.0843 0 0 0 0 1.0844 3 1 -4 0 1.0845 2 0 -1 0 1.0846 3 0 -3 0 1.0847 0 0 0 0 1.0848 0 0 0 0 1.0849 -2 0 -1 0 1.0850 -3 0 -3 -1
LehBotSize = Net trades by Bots in the LEH stack against customer orders LehCJCSize = Net trades by CJC or AGB in the LEH stack against customer orders DarBotSize = Net trades by Bots in DAR DarCJCSize = Net trades by CJC in DAR
Plot of Risk Book FIGURE 105 illustrates a plot of a risk book.
LehBotSize = Dark Blue LehCJCSize = Light blue DarBotSize = Orange DarCJCSize = Brown
Average price of open position = Green line (a opposite position at this price and size will net an overall zero P&L) Size of open position = Text adjacent to green line
Market price = Dashed grey line Unrealized P&L = Text adjacent to dashed grey line
I -NY/1922975.1 163 Plot of Net Risk FIGURE 106 illustrates a plot of a net risk.
Net Position at Price: Leh>Dar = Dark Blue Net Position at Price: Dar>Leh = Magenta
Average price of open position = Green line Size of open position = Text adjacent to green line
1-NY/1922975.1 164 Appendix B l-NY/1922443.1 Match Engine Executive Summary: This document will describe an embodiment of an implementation of a Match Engine ("ME4").
Introduction: ME4 is a message oriented, single threaded application that performs matching and automated market making based on specified business rules. Primary functions performed by ME4 are:
1) Accept incoming orders (FX) and validate them based on symbol, quantity limits and sender information. 2) Perform necessary market actions on the order: (match, insert into order book, cancel existing order etc). Matching is done on a price-time priority basis. If an incoming order is match-able, it is matched instantly. 3) Produce execution reports as confirmation of market actions: (fill, partial fill, new order, cancel confirm etc). 4) Provide liquidity extension by creating market maker orders predicated on existing liquidity providers in the stack. 5) Perform all above tasks in a fault tolerant manner.
DETAILS: Messaging: ME4 can use reliable Tibrv multicast as the messaging medium. Orders entered on a GUI client are relayed to a web server and converted into a tibrv message sent on a subject earmarked for orders. Orders entered via FIX are converted into tibrv messages by a third party application (FIX/tibrv converter) and sent on the same subject. ME4 registers interest in all messages on the order subject and sees all orders regardless of the input medium as one order stream. Execution Reports produced by ME4 are similarly multicast on an execution report subject. Clients (GIU application, FIX/tib converter) interested in receiving execution reports register an interest in the global execution report subject or a part of the subject namespace that corresponds to their orders.
l-NY/1922443.1 Inbound: Order messages sent to ME4 use standard plain text fieldname=value type messages. The size of the message text is variable based on the number of characters used and is generally about 3 to 5 times larger than the size of the compressed byte message format used by ME4. The messages are decoded at the ME4 and converted into an order object that the application works on. The field naming semantics borrows heavily from the FIX message protocol and in general all messages to and from ME4 are 99% FIX compatible. The exception being, some additional fields that ME4 adds to messages to provide extra information that is not specified in the FIX protocol.
Outbound: Execution reports sent from ME4 use a proprietary compressed byte format (CBF). Data in the messages is comprised of US ASCII plain text and network byte order numeric information. Generally all double precision values are converted into a 6 byte engineering format with a 4 byte mantissa and a 2 byte base 10 exponent. Further, strings are represented as a 2 byte header and a sequence of 1 byte fields representing individual characters. All integer values are 4 byte network byte order fields. The nature of the message provides optimum compression with minimum parsing overhead and a memory layout optimized for improved CPU and cache performance while parsing and encoding (high locality of reference).
Field names are implicit in the message structure design and thus are not relayed with every message. This provides enormous savings in overall message size. Further the CBF format lends itself easily to other means of transporting such as session oriented socket streams and socket datagrams. Typical size of an execution report is 206 bytes.
Structure: There are 6 main operating sections in ME4: NetworkAdapter, MarketManager, StackEngine, Message Parser/Encoder, ClusterAdapter and ClusterMsgFilter
Network Adapter: The network adapter is a connection class that provides connectivity and message passing capabilities. It is a virtual class than can be used as an interface for creating new messaging media. One concrete implementation of the Network Adapter is the Tibrv Adapter that performs the above functions using reliable tibrv messages. 3 l-NY/1922443.1 Message Parser/Encoder: The message parser is a filter class that provides conversion utilities from ME4 objects to CBF messages and back. The filter class is called on by the Tibrv Adapter to encode and decode messages as they are sent or received.
ClusterAdapter: The ClusterAdapter is a connection class that provides Tibrv based cluster message communications.
ClusterMsgFilter: Similar to the Message Parser/Encoder, this is a filter class that provides conversion utilities from ME4 cluster objects to CBF format messages and back.
StackEngine: The StackEngine is responsible for performing all actions connected with matching and order management. It has entry points to the K engine and encoders/decoders from ME4 objects to K objects. Orders are relayed virtually unchanged to the K engine where they are acted upon by vector matching functions and finally inserted into the book or an action specified by the order is performed.
MarketManager: The MarketManager provides order validation, credit verification and cluster management functionality. It acts as a director of traffic and maintains an order stack of its own that mirrors the K stack and uses it to synchronize processes in a cluster.
Figure 107 illustrates an embodiment of the main operating sections of a match engine. As shown, the following sections can have the following functionalities:
Market Manager: 1. On new order, enter in pre-stack 2. Send order to stack engine. 3. Receive execution reports from stack engine and relay to network adapter. 4. Check state of all ME in cluster. 5. Perform fault tolerant actions.
Stack Engine: 1. Receive order from MarketManager, perform match functions. 2. Send execution reports to MarketManager. 4 l-NY/1922443.1 3. Generate market data and send to MarketManager.
Message Parser/Encoder: 1. Parse network text and CBF messages and create high level objects. 2. Encode high level market objects into CBF messages.
ClusterMsgFilter: 1. Parse network text and CBF messages from ClusterAdapter and create high level cluster objects (heartbeats, mgmt messages). Send cluster objects to ClusterAdapter. 2. Receive high level cluster objects from ClusterAdapter. Encode into CBF messages and return to ClusterAdapter.
TibrvAdapter: 1. Receive market objects from MarketManager, send to message parser for encoding. Send CBF message on required subject. 2. Receive CBF message from network. Send to Message Parser for parsing. Send market object to MarketManager for processing.
ClusterAdapter: 1. Receive CBF heartbeats and management messages from network and send to ClusterMsgFilter. Receive cluster object and send to MarketManager. 2. Send Cluster object to ClusterMsgFilter for conversion to CBF format. Receive CBF format message from filter and send to network.
Clustering: ME4 uses a clustering approach to high availability. An ME4 cluster typically consists of two or more engines.
The primary engine accepts orders from the consolidated order stream and processes it. After processing is complete, the order is sent to all the secondary engines and any execution reports are sent to the client. This ensures that an order is always sent out before execution reports are published. Further, the engines publish and listen to each others heartbeats every second. Every two seconds a status check is done by every engine on every other engine. Since the orders being sent to the other engines are a reliable multicast, all engines might not 5 l-NY/1922443.1 get the orders at the same time. Thus the checks use a tolerance factor of five standard deviations from the average order rate calculated over the past 120 seconds. In the event of a quite market, the order rate drops to zero and any engines that missed orders are then dropped from the cluster.
Figure 108 illustrates an embodiment of the MatchEngine Cluster Topography. Three separate Tibrv network settings are used for the cluster.
1. External TIB: The external TIB is the Tibrv interface that connects the ME4 cluster to clients and databases. The consolidated order stream is received and execution reports are sent out on this pipe. As can be seen in the topo diagram, only the primary MatchEngine listens on and publishes to the external TIB.
2. Internal TIB: The internal tib is used by the primary MatchEngine to send orders to the backup MatchEngines. Each backup engine then individually processes each order.
3. Cluster TIB: The cluster TIB is the tibrv interface used by all MatchEngines to exchange cluster heartbeats and control messages. External management commands are also received on this pipe.
Operation Details: 1. Initialization: The MatchEngine downloads connection and system startup parameters from an LDAP repository. The initialization information is used to set up connections, create queues and static objects. The engine then starts to listen on the external and the internal order stream and the cluster stream. Any orders received in this time are discarded.
2. Discovery: The system then listens for ten seconds in a special mode called discovery that allows it to detect if members already exist. If there are no existing members, the system then creates a Tibco FT member and changes its state to running. If it finds that other members exist then for each member, it creates a member entry in the cluster database and sends a hello message to each existing member. The hello message allows existing members to create member entries for this member. It then 6 l-NY/1922443.1 locates the current cluster master and sends it a sync request. The cluster master uses the sync request details to send the entire stack in CBF format to the member. The new member then processes the stack information before processing orders. In the Sync response is the last order sequence number that corresponds to the sync response. The member starts accepting orders on the internal tib and discards all orders up to that sequence number.
3. Master: When the Tibco FT components give a process the activate callback, the process then starts processing messages received on the external TIB, receives orders, sequences them and after processing the order, relays the order on the internal TIB to all listening processes. This maintains the primary always at one order ahead of the back up processes. After sending the order on the internal TIB, the process then puts any execution reports on the external TIB for consumption by clients.
4. Passive Member: When a member has activated and synchronized from the master, it changes its state to RUNNING and starts processing orders sent by the master on the internal TIB. On each order, it resets its internal sequence generator to stay in sync with the master and processes the order. It does not send any execution reports but keeps track of the number of execution reports generated and the number of orders consumed.
5. Cluster Management: Every second, each cluster member queries the available system memory and current memory load to adjust its cluster weight. This is used to decide order of activation with the process with the lowest memory load getting highest priority. It then checks on the heartbeat times of the other members. Using a fine-tuned strategy to infer problems, the Engine is able to tell when a particular process (including itself) is in good health or not. Each process statistically analyzes sending times, receipt times and transmission delays to detect delays in the processes and the network. Further, heartbeat timeouts let a process know that some other process has expired. When any analyzed process displays problems, each process in the cluster sends it a status change message. The process in question receives these messages and performs actions on them such as reduce its activation priority level, synchronize with the master or exit immediately.
l-NY/1922443.1 6. Matching Algorithm: The core of the MatchEngine is a K script that is loaded into a K dll at init. The script declares routines, functions and helpers that allow the K engine to perform order matching and stack management.
On receipt of a new order, the StackEngine determines if the price of the order is such that it adds liquidity and changes top of stack information (either by providing a better price or adding quantity) it then updates the top of stack information accordingly, queues the order, sends an ack to the client that owns the order and the top of stack message to all clients.
If the price is such that order will take liquidity, the order is allowed to do that immediately and execution reports are sent to all clients that participated in the match. The new top of stack is then obtained and sent to all clients.
Top of Stack and Market Depth: Every second, all the stack information upto the first 15 orders is compiled into a stack message and sent to all clients to relay market depth information. Further, the existing top of stack information is resent to all clients.
Match Engine Message Formats
Executive Summary This document describes data formats and field explanations for message formats used by ME4.
Inputs New Order Single The new order single is used to send orders to ME4. New Order Single is the only clear text message accepted by ME4. All other messages use compressed byte sequence format. New Order Singles should be published on the following TIB subject:
LEH.EFX.MLN.DEALS.IN.<SYMBOL>.<SENDERCOMPID>.<SENDERSUBID>.<MSGTYPE>
The field names and data types are as follows:
8 l-NY/1922443.1
Figure imgf000201_0001
The minimum order qty is IMM and maximum order qty is 100 MM. FutSettDate2: If present, the field designates the roll-to date for a NDF roll order. OrderID: Required for cancels. This is the ME4 assigned OrderID received in the Acknowledgement message from ME4. TimelnForce: Only GOOD_TILL_CANCEL and IMMEDIATE_OR_CANCEL are supported TimelnForce types. SettlmntTyp: Set field to "1" for NDF-CASH roll orders. Set to general otherwise. Account is a required field and the account name must be a valid account assigned to the Trading Entity indicated by the SenderCompID and the SenderSubID fields.
Credit Update Credit update messages are sent to the ME on the subject: LEH.EFX.MLN.CREDIT.UPDATE Credit updates are sent in compressed byte sequence format with the following structure.
CreditCell MsgSize 4 Symbol 2+n
1 -NY/1922443.1
Figure imgf000202_0001
MsgSize: A 4 byte field that indicates the size of the message that follows. (Does not include the size of the header). CompIDl : The integer CompID assigned to the firm as a 4 byte field. CompID2: The integer CompID assigned to the firm as a 4 byte field. BaseValue: The unsigned long base credit limit assigned to this firm.
Outputs The primary outputs of ME4 are execution reports. These are classified as ACK and EXEC messages. ACK messages are acknowledgement, expiration, cancel and reject messages while fills and partial fills fall in the EXEC category.
NOTE: OrdRejReason is an optional field that will only be present if the ExecType of the ack is "8" REJECTED. For all other acks, there is no OrdRejReason. Account is directly followed by SequenceNumber and ExecSequenceNumber.
ACK Acks are sent by ME4 on the subject: LEH.EFX.MLN.DEALS.OUT.<TargetCompID>.<TargetSubID>.<MsgType>
Figure imgf000202_0002
10 l-NY/1922443.1
Figure imgf000203_0001
Strings are represented by a packed sequence of bytes excluding the trailing NULL preceeded by the number of characters (bytes) in the character sequence. Sequencing:, ME4 uses independent sequence numbers for orders and execution reports. However because some sequence numbers are consumed internally, it is not possible to guarantee equal increment steps in the Sequence Numbers. Eg: The text "MATCHENGINE" would be represented as:
Figure imgf000203_0002
EXEC Exec messages are sent on the subject: 11 l-NY/1922443.1 LEH.EFX.MLN.DEALS.OUT.<TargetCompID>.<TargetSubID>.<MsgType>
Figure imgf000204_0001
Figure imgf000204_0002
Figure imgf000204_0003
The MatchPrice field of the EXEC message carries the ME4 calculated execution price based on the actual price of the order. This is relevant for matches in the NDF Roll and the NDF- 12 l-NY/1922443.1 Cash roll categories. Such matches receive a blended execution price that are based on the midpoint of the BID-ASK for the spot date and then offset by the amount of the trade.
Eg: With spot date quoted at 1.1662-1.1670 for EUR/USD, any matches on the Roll stacks will receive an AvgPx of around 1.1666 although rolls might be priced around 0.0013. The MatchPx field stores the actual price of the match based on the quoted roll price.
Market Data
All best bid offer information in ME4 is now real time. That is, a new top of stack price is immediately reflected in a best bid offer message. When no new price changes occur, one second refreshes of the last sent information are published.
NOTE: The MDEntryType field of all market data confirms to the FIX side code with BUY = "1" and SELL = "2". This is different from the FIX code for MDEntryType that specifies BUY = "0" and SELL = "1".
Market Data is published on the subject
LEH.EFX.MLN.MD.<Symbol>.<F/FR>.<FutsettDate>.<SettImntTyp>.X
Figure imgf000205_0001
13 l-NY/1922443.1 FR in the subject indicates that this market data message applies to the roll stack with FutSettDate as the trailing edge (the roll from stack). F implies that the message is the outright stack with FutSettDate indicating the stack to which this market data applies
The shaded gray area in the above message signifies a repeating structure of four fields. The number of repetitions is equal to the NoMDEntries field which is the last scalar field before the repeating structure starts.
If the value of NoMDEntries reads 0, that indicates that no data is available for that particular symbol (stack is empty). The message will then have no fields following the NoMDEntries field.
Event based market data remains unchanged.
Settlement Data
Settlement data is a one second interval message that provides the latest settlement price information along with the three trading dates currently active in the market.
Settlement data is published on the subject:
LEH.EFX.MLN.SETTLE.OUT.<SYMBOL>
Figure imgf000206_0001
14 l-NY/1922443.1 OpenCloseSettlFlag is a one byte field that has a value 0 or 1. 0 Indicates that the contract has not settled and 1 indicates that it has. The price is the settlement price of the contract. The contract in question is the NDF stack for today's date.
Order Book Snapshot
Two kinds of order book snapshots are available. The general order book snapshot is a one second interval snapshot of all orders up to the top 15 in the stack for a particular symbol and a particular settlement date.
The general snapshot is available on the subject:
LEH.XFX.MLN.STACK.OUT.<SYMBOL>.W
Figure imgf000207_0001
These snapshots are available for all the outright stacks and the NDF-RoIl stacks.
Further, a special snapshot is published on the subject: 15 l-NY/1922443.1 LEH.XFX.MLN.ENTITY.STACK.OUT.<Compro>.<Symbol>.W
This snapshot is a comprehensive stack of all orders in the Roll-Cash stack that are compatible orders for this entity to match against based on the entity's credit relationships with other entities in the market.
Figure imgf000208_0001
The items in the red box is a list of current credit base amounts and available amounts for this entity and the snapshot data that follows is the list of all orders that this entity is allowed to trade against. Typically client applications will dynamically create a subscription to this stack when the user enters a Roll-Cash trade and delete the subscription when the size of the stack goes to zero (the client is no longer active in the market). Static subscriptions can also be made on
16 l-NY/1922443.1 these subjects however stacks will not be published until the first entity that has any credit relationship with anyone enters an order. If the value of NoCreditltems reads 0, there are no credit items in the message and the next field is read as a 2 byte NoMDEntries field. If that value reads 0 then the message will have no fields following the NoMDEntries field.
Additional Messages Heartbeats Heartbeats are published by every active ME4 that is in a live cluster. A cluster is defined as a group of at least one process that is designated as the master. Heartbeats are published on the subject:
LEH.SERVER.ME.MGMT.HEARTBEAT.<InstanceID>
Figure imgf000209_0001
Status Request The structure of the status request message is very similar to that of an order message. That is, SenderCompID, SenderSubID and ClOrdID are required fields. The MsgType of the Order will read STATUS REQUEST. The reply from ME4 will be a status response in the form of an execution report. Status requests are sent on the same subject as Orders.
17 l-NY/1922443.1 LEH.EFX.MLN.DEALS.IN.<SYMBOL>.<SENDERCOMPID>.<SENDERSUBID>.<MSGTYPE>
Cancel AU Cancel All messages can be sent when a FIX or web client is disconnected to clear their existing orders from the stack. Cancel All will only remove existing orders from the stack. It does not preclude the client from trading again. That is, cancel all does not automatically prevent further orders from being accepted.
Cancel All messages are sent in Compressed Byte format.
Figure imgf000210_0001
Since Cancel All messages apply by Symbol. In order to clear all the orders for a particular client, this message is sent as many times as there are symbols. LEH.SERVER.ME.MGMT.CMD.CCL.SYMBOL.<symbol>
Market Heartbeat Clients to ME4 do not have to listen to cluster heartbeats described above. For clients, the active ME4 publishes a market heartbeat on the subject:
LEH.MARKET.STATUS The format of the Market heartbeat message is:
Figure imgf000210_0002
The presence of a market heartbeat indicates a live market. Absence of the heartbeat indicates that the market is down or unreachable. 18 l-NY/1922443.1 The market name indicates the name of the market. For FX markets, the name is "LEHMAN FX MARKET".
Status carries one of the following three values: OPEN (6:00:00 PM Sunday to 6:00:00 PM Friday) CLOSED (6:00:00 PM Friday to 6:00:00 PM Sunday) ERROR (when the market status is invalid).
Orders will only be accepted when market status reads OPEN. For all other status types, orders will be rejected with the OrdRejReason set to EXCHANGE CLOSED.
19 l-NY/1922443.1

Claims

CLAIMSWhat is claimed is:
1. A computer-implemented method for currency exchange comprising:
electronically receiving data regarding a first plurality of currency bids and a first plurality of currency offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of bids and said first plurality of offers are associated with a first settlement date;
electronically receiving data regarding a second plurality of currency bids and a second plurality of currency offers, said data comprising prices and quantities for said second plurality of bids and said second plurality of offers, wherein said second plurality of bids and said second plurality of offers are associated with a second settlement date;
displaying said first plurality of bids and said first plurality of offers in a first arrangement corresponding to said first settlement date and displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers; and
displaying said second plurality of bids and said second plurality of offers in a second arrangement corresponding to said second settlement date and displaying at least some of said prices and quantities for said second plurality of bids and said second plurality of offers;
wherein said first arrangement and said second arrangement are displayed simultaneously to a user.
2. The method of claim 1, wherein said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for displaying offers corresponding to said first settlement date, and wherein said second arrangement comprises a third column for displaying bids corresponding to said second settlement date and a fourth column for displaying offers corresponding to said second settlement date.
3. A computerized system for currency exchange comprising:
a communication component operable to receive currency exchange data regarding -NY/1922896.1 27 bids and offers for a first settlement date and a second settlement date;
a display component operable to display said currency exchange data for said first settlement date in an arrangement corresponding to said first settlement date, and said currency exchange data for said second settlement date in an arrangement corresponding to said second settlement date, wherein said first arrangement and said second arrangement are displayed simultaneously to a user.
4. The system of claim 3, wherein
said currency exchange data regarding bids and offers for said first settlement date comprises
a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity, and
said currency exchange data regarding bids and offers for said second settlement date comprises
a plurality of bids each comprising a bid price and a bid quantity, and a plurality of offers each comprising an offer price and an offer quantity.
5. The system of claim 3, wherein said currency exchange data for said first settlement date is displayed in a first arrangement corresponding to said first settlement date, said first arrangement displaying at least some of said prices and quantities for said first plurality of bids and said first plurality of offers, and said currency exchange data for said second settlement date is displayed in a second arrangement corresponding to said second settlement date, said second arrangement displaying at least some of said prices and quantities for said second plurality of bids and said second plurality of offers.
6. The system of claim 5 wherein said first arrangement comprises a first column for displaying bids corresponding to said first settlement date and a second column for displaying offers corresponding to said first settlement date, and wherein said second arrangement comprises a third column for displaying bids corresponding to said second settlement date and a fourth column for displaying offers corresponding to said second settlement date.
7. The system of claim 3 wherein
-NY/1922896.1 28 US2005/022187
said communication component is operable to receive currency exchange data regarding bids and offers for a third settlement date; and
said display component is operable to display said currency exchange data regarding bids and offers for said third settlement date in an arrangement corresponding to said third settlement date and at least one of price and quantity, wherein said currency exchange data for said third settlement date is displayed simultaneously with said currency exchange data for said first and second settlement dates.
8. The system of claim 3 further comprising a matching component operable to match at least one bid and at least one offer related to a particular settlement date.
9. The system of claim 3 further comprising a rolling component operable to roll one or more currency exchange trades from said first settlement date to said second settlement date.
10. The system of claim 9, wherein a currency exchange trade rolled from said first settlement date to said second settlement date results in said currency trade settling on said second settlement date.
11. A computer-implemented method for foreign currency exchange comprising:
electronically receiving data regarding a first plurality of roll bids and a first plurality of roll offers, said data comprising prices and quantities for said first plurality of bids and said first plurality of offers, wherein said first plurality of roll bids are associated with a first settlement date, and said first plurality of roll offers are associated with a second settlement date;
displaying said first plurality of roll bids in a first arrangement corresponding to said first settlement date and at least one of price and quantity;
displaying said first plurality of roll offers in a second arrangement corresponding to said second settlement date and at least one of price and quantity; and
rolling a currency exchange trade from said first settlement date to said second settlement.
12. The method of claim 11 wherein rolling a currency exchange trade from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date. -NY/1922896.1 29 87
13. A system for foreign currency exchange comprising:
a communication component operable to receive currency exchange data regarding one or more roll bids for a first settlement date and one or more roll offers for a second settlement date, wherein each of said one or more roll bids corresponds to a distinct currency trade, and each of said one or more roll offers corresponds to a distinct currency trade;
a display component operable to display said one or more roll bids in an arrangement corresponding to said first settlement date and at least one of price and quantity, and said one or more roll offers in an arrangement corresponding to said second settlement date and at least one of price and quantity; and
a rolling component operable to roll a currency exchange trade from said first settlement date to said second settlement date.
14. The system of claim 13, wherein said one or more roll bids each comprises a roll bid price and a roll bid quantity, and said one or more roll offers each comprise a roll offer price and a roll offer quantity.
15. The system of claim 13, wherein a currency exchange trade rolled from said first settlement date to said second settlement date results in said currency exchange trade settling on said second settlement date.
l-NY/1922896.1 30
PCT/US2005/022187 2004-06-22 2005-06-22 Methods and apparatus for online foreign currency exchange WO2006002294A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US58236704P 2004-06-22 2004-06-22
US60/582,367 2004-06-22

Publications (2)

Publication Number Publication Date
WO2006002294A2 true WO2006002294A2 (en) 2006-01-05
WO2006002294A3 WO2006002294A3 (en) 2007-01-18

Family

ID=35782334

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/022187 WO2006002294A2 (en) 2004-06-22 2005-06-22 Methods and apparatus for online foreign currency exchange

Country Status (1)

Country Link
WO (1) WO2006002294A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112328424A (en) * 2020-12-03 2021-02-05 之江实验室 Intelligent anomaly detection method and device for numerical data
US11406242B2 (en) 2020-04-14 2022-08-09 Whirlpool Corporation Dishwasher with sound attenuation

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
US6343278B1 (en) * 1998-09-04 2002-01-29 Ebs Dealing Resources, Inc. Combined order limit for a group of related transactions in an automated dealing system
US20030147309A1 (en) * 2002-02-06 2003-08-07 Philip Weisberg Electronic market calendar

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5168446A (en) * 1989-05-23 1992-12-01 Telerate Systems Incorporated System for conducting and processing spot commodity transactions
US6343278B1 (en) * 1998-09-04 2002-01-29 Ebs Dealing Resources, Inc. Combined order limit for a group of related transactions in an automated dealing system
US20030147309A1 (en) * 2002-02-06 2003-08-07 Philip Weisberg Electronic market calendar

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11406242B2 (en) 2020-04-14 2022-08-09 Whirlpool Corporation Dishwasher with sound attenuation
US11678785B2 (en) 2020-04-14 2023-06-20 Whirlpool Corporation Dishwasher with sound attenuation
CN112328424A (en) * 2020-12-03 2021-02-05 之江实验室 Intelligent anomaly detection method and device for numerical data

Also Published As

Publication number Publication date
WO2006002294A3 (en) 2007-01-18

Similar Documents

Publication Publication Date Title
US11636544B2 (en) Method and apparatus for order entry in an electronic trading system
US20190392522A1 (en) Distributed data processing
CN102859938B (en) Calculate resource by networking and data are carried out the device of synchronization process, system and method
AU755413B2 (en) Communication of credit filtered prices in an electronic brokerage system
US5243331A (en) Keypad for computer system
US10510114B2 (en) Distributed trading bus architecture
US20110184847A1 (en) Data storage and processor for storing and processing data associated with derivative contracts and trades related to derivative contracts
US11025562B2 (en) Activity based electrical computer system request processing architecture
WO2003036540A1 (en) Volume weighted average price system and method
WO2001033316A2 (en) Method and system for trading user-definable baskets of fungible goods such as securities
US20020023043A1 (en) System and method for supporting odd lot trading
CA2905634C (en) Methods, systems and components for integrating purchase and sale of mutual fund units with dealer equity order management systems
WO2006002294A2 (en) Methods and apparatus for online foreign currency exchange
EP1503309A1 (en) Data validity control in straight-through processing systems
JP2003536167A (en) Structured anonymous trading system
Derviz Components of the Czech koruna risk premium in a multiple-dealer fx market
Papalexiou An analysis of the impact of high frequency trading on equity markets
Derviz Continuous time decision-making in a partially decentralized multiple dealership forex market, and the equilibrium exchange rate

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

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

NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 05763171

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 05763171

Country of ref document: EP

Kind code of ref document: A2