+

WO2006002294A2 - Procedes et appareil d'echange de monnaies etrangeres en ligne - Google Patents

Procedes et appareil d'echange de monnaies etrangeres en ligne 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
English (en)
Other versions
WO2006002294A3 (fr
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/fr
Publication of WO2006002294A3 publication Critical patent/WO2006002294A3/fr

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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne : (1) le traitement de la transparence à cours limité ; (2) le traitement de la domination en parts de marché aux mains des grandes banques ; (3) le traitement des efforts concurrentiels du passé qui ont échoué; et (4) le traitement du problème des coût associés à des transactions monétaires. Divers aspects de l'invention concernent ces questions. A titre d'exemple seulement, la mise en oeuvre du logiciel selon l'invention offre davantage de transparence à l'évolution boursière que les systèmes antérieurs ; l'aspect contrat à terme non livrable, NDF, selon l'invention, traite de la question du coût du règlement ; et l'aspect ouvert à tous les participants traite des questions d'oligopole et de structure des bénéfices. Dans un aspect, l'invention concerne un système de monnaie non livrable ouvert à tous les participants au marché avec pleine capacité d'absorption du marché.
PCT/US2005/022187 2004-06-22 2005-06-22 Procedes et appareil d'echange de monnaies etrangeres en ligne WO2006002294A2 (fr)

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 (fr) 2006-01-05
WO2006002294A3 WO2006002294A3 (fr) 2007-01-18

Family

ID=35782334

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/022187 WO2006002294A2 (fr) 2004-06-22 2005-06-22 Procedes et appareil d'echange de monnaies etrangeres en ligne

Country Status (1)

Country Link
WO (1) WO2006002294A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112328424A (zh) * 2020-12-03 2021-02-05 之江实验室 一种用于数值型数据的智能异常检测方法及装置
US20220215359A1 (en) * 2019-04-30 2022-07-07 Harexinfotech Inc. Settlement server and method thereof
US11406242B2 (en) 2020-04-14 2022-08-09 Whirlpool Corporation Dishwasher with sound attenuation

Family Cites Families (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
WO2003073302A1 (fr) * 2002-02-06 2003-09-04 Fx Alliance, Llc Calendrier de commerce electronique

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220215359A1 (en) * 2019-04-30 2022-07-07 Harexinfotech Inc. Settlement server and method thereof
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
US12114824B2 (en) 2020-04-14 2024-10-15 Whirlpool Corporation Dishwasher with sound attenuation
CN112328424A (zh) * 2020-12-03 2021-02-05 之江实验室 一种用于数值型数据的智能异常检测方法及装置

Also Published As

Publication number Publication date
WO2006002294A3 (fr) 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
AU755413B2 (en) Communication of credit filtered prices in an electronic brokerage system
AU2003238004B2 (en) System and method for estimating and optimizing transaction costs
US7890412B2 (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
CN102859938A (zh) 通过网络化计算资源对数据进行同步处理
US20240106765A1 (en) Activity based electrical computer system request processing architecture
WO2003036540A1 (fr) Systeme et procede a prix moyen pondere en fonction du volume
WO2001033316A2 (fr) Procede et systeme permettant de negocier des paniers, definissables par l'utilisateur, de biens fongibles tels que des titres
CA2905634C (fr) Methodes, systemes et composants destines a l'integration d'achat et de vente d'unites de fonds communs de placement aux systemes de gestion d'ordre boursier du vendeur
WO2006002294A2 (fr) Procedes et appareil d'echange de monnaies etrangeres en ligne
EP1503309A1 (fr) Contrôle de la validité de données dans des systèmes du traitement continu
JP2003536167A (ja) 構造化可能な匿名取引システム
Papalexiou An analysis of the impact of high frequency trading on equity markets
Derviz Components of the Czech koruna risk premium in a multiple-dealer fx market
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

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

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载