User-defined algorithm electronic trading
14 claims: 3 independent, 11 dependent
- 1ビジュアルプログラミング環境に作成されたブロックの配置に対応するコンピュータプログラムコードを実行するプロセッサを備えるシステムであって、 ブロックの配置は、取引アルゴリズムを定義するものであり、 コンピュータプログラムコードは、 特定の外部イベントおよび/又は内部イベントの通知のために登録可能な イベントハンドラ であって、外部イベントおよび/又は内部イベントが生成されると、登録された各 イベントハンドラ が起動されることで、各ブロックに対応するコンピュータプログラムコードが、生成されたイベントに応じた1つ又は複数の機能を実行可能となる、 イベントハンドラ を含み、 外部イベントは、取引アルゴリズムの状態を変化させる市場又はタイマーのアクションを含み、内部イベントは、 イベントハンドラ によって生成され、 外部イベントに応じて、プロセッサは、 当該外部イベントに関連して登録されている各 イベントハンドラ を起動するステップ、ここで、 イベントハンドラ のうちの少なくとも1つが内部イベントを生成する、 当該外部イベントに関連する イベントハンドラ のうちの少なくとも1つが内部イベントを生成する場合に、当該内部イベントに関連して イベントハンドラ が登録されているブロックを、処理すべきブロックのリストに追加するステップ、 当該外部イベントに関連する イベントハンドラ による処理が完了すると、生成された内部イベントに関連して登録されている各 イベントハンドラ を起動することにより、リスト内の当該内部イベントに関連するブロックのコンピュータプログラムコードを実行するステップ、 を実行する、システム。
- 2生成された内部イベントは、第1の内部イベントであり、 第1の内部イベントに応じて、プロセッサは、 第1の内部イベントに関連して登録されている各 イベントハンドラ を起動するステップ、ここで、各 イベントハンドラ のうちの少なくとも1つは、第2の内部イベントを生成する、 各 イベントハンドラ のうちの少なくとも1つが第2の内部イベントを生成している場合に、生成された第2の内部イベントに関連して登録されている各 イベントハンドラ のブロックを、処理すべきブロックのリストに追加するステップ、 第1の内部イベントに関連する イベントハンドラ による処理が完了すると、生成された第2の内部イベントに関連して登録されている各 イベントハンドラ を起動することにより、第2の内部イベントに関連するリスト中のブロックのコンピュータプログラムコードを実行するステップ、 を実行する、請求項1に記載のシステム。
- 3生成された所定のイベントに関連して登録されている イベントハンドラ は、当該イベントに対して不特定の順序で評価される、請求項1又は2に記載のシステム。
- 4生成された所定のイベントに関連して登録されている イベントハンドラ は、ビジュアルプログラミング環境においてそれぞれのブロックが配置される順序に基づいて評価される、請求項1又は2に記載のシステム。
- 5外部イベントおよび内部イベントは、特定の時点で発生する特定のアクションに対応する離散イベントである、請求項1から4のいずれか1つに記載のシステム。
- 6取引アルゴリズムは、1つの入力部と少なくとも2つの出力部とを備えるシーケンサーブロックを備え、出力部のそれぞれは、離散イベントに関連して登録されている イベントハンドラ の1つ又は複数のブロックの入力部に接続されており、シーケンサーブロックは、離散イベントが出力部に提供される順序を制御することにより、 イベントハンドラ が起動される順序を制御する、請求項5に記載のシステム。
- 7ビジュアルプログラミング環境で生成されるブロックの配置に対応するコンピュータプログラムコードを実行する方法であって、 ブロックの配置は、取引アルゴリズムを定義するものであり、 コンピュータプログラムコードは、 特定の外部イベントおよび/又は内部イベントの通知のために登録可能な イベントハンドラ であって、外部イベントおよび/又は内部イベントが生成されると、登録された各 イベントハンドラ が起動されることで、各ブロックに対応するコンピュータプログラムコードが、生成されたイベントに応じた1つ又は複数の機能を実行可能となる、 イベントハンドラ を含み、 外部イベントは、取引アルゴリズムの状態を変化させる市場又はタイマーのアクションを含み、内部イベントは、 イベントハンドラ によって生成され、 外部イベントに応じて、以下のステップを実行する、 当該外部イベントに関連して登録されている各 イベントハンドラ を起動するステップ、ここで、 イベントハンドラ のうちの少なくとも1つが内部イベントを生成する、 当該外部イベントに関連する イベントハンドラ が起動されたブロックが現在それぞれのコンピュータプログラムコードを実行している場合に、生成される内部イベントに関連して登録されている イベントハンドラ のブロックを、処理すべきブロックのリストに追加するステップ、 当該外部イベントに関連する イベントハンドラ による処理が完了すると、生成された内部イベントに関連して登録されている各 イベントハンドラ を起動することにより、リスト内の当該内部イベントに関連するブロックのコンピュータプログラムコードを実行するステップ、 方法。
- 8生成された内部イベントは、第1の内部イベントであり、 第1の内部イベントに応じて、以下のステップをさらに実行する、 第1の内部イベントに関連して登録されている各 イベントハンドラ を起動するステップ、ここで、各 イベントハンドラ のうちの少なくとも1つは、第2の内部イベントを生成する、 第1の内部イベントに関連して各 イベントハンドラ のうちの少なくとも1つが第2の内部イベントを生成している場合に、生成された第2の内部イベントに関連して登録されている各 イベントハンドラ のブロックを、処理すべきブロックのリストに追加するステップ、 第1の内部イベントに関連して イベントハンドラ が起動された イベントハンドラ のブロックが現在、それぞれのコンピュータプログラムコードを実行する場合に、生成された第2の内部イベントに関連して登録されている イベントハンドラ のブロックを、処理すべきブロックのリストに追加するステップ、 第1の内部イベントに関連する イベントハンドラ による処理が完了すると、生成された第2の内部イベントに関連して登録されている各 イベントハンドラ を起動することにより、第2の内部イベントに関連するリスト中のブロックのコンピュータプログラムコードを実行するステップ、 請求項7に記載の方法。
- 9さらに、 生成された所定のイベントに関連して登録されている イベントハンドラ を、当該イベントに対して不特定の順序で評価するステップ、 を含む、請求項7又は8に記載の方法。
- 10さらに、 生成された所定のイベントに関連して登録されている イベントハンドラ を、ビジュアルプログラミング環境においてそれぞれのブロックが配置される順序に基づいて評価するステップ、 を含む、請求項7又は8に記載の方法。
- 11外部イベントおよび内部イベントは、特定の時点で発生する特定のアクションに対応する離散イベントである、請求項7から10のいずれか1つに記載の方法。
- 12取引アルゴリズムは、1つの入力部と少なくとも2つの出力部とを備えるシーケンサーブロックを備え、出力部のそれぞれは、離散イベントに関連して登録されている イベントハンドラ の1つ又は複数のブロックの入力部に接続されており、 さらに、 シーケンサーブロックが離散イベントを出力部に提供する順序を制御することにより、 イベントハンドラ が起動されるシーケンスを制御するステップ、 を含む、請求項11に記載の方法。
- 13請求項7から12のいずれか1つに記載の方法を処理システムに実行させるためのコンピュータプログラム。
- 14請求項7から12のいずれか1つに記載の方法を処理システムに実行させるための命令を記憶したコンピュータ読み取り可能媒体。
Independent claims14
298 paragraphs, as filed
Cross-reference of related applications This application is filed on October 20, 2009, entitled "Trading Application Using Future Ranking and Ordering Tool, Price Level Indicator Tool and Market Change Hearing Indicator Tool", US Provisional Patent Application No. 61 / 253,315, 2009. US Provisional Patent Application No. 61 / 253,324, entitled "Systems and Methods for Building User-Defined Electronic Transaction Exchange Algorithms," filed October 20, 2009, "User-Defined Electronics," filed November 20, 2009. US Provisional Patent Application No. 61 / 263,300, entitled "Systems and Methods for Building Trading Exchange Algorithms," US, entitled "Systems and Methods for Launching Automated Trading Applications," filed March 9, 2010. Provisional Patent Application No. 61 / 312,003, US Provisional Patent Application No. 61 / 318,685, 2010, entitled "Systems and Methods for Virtualizing User-Defined Electronic Transaction Exchange Algorithms," filed March 29, 2010. US Provisional Patent Application No. 61 / 320,061, filed April 1, 2010, entitled "Systems and Methods for Automating Feedback-Based User-Defined Electronic Transaction Exchange Algorithms," filed October 14, 2010. US Provisional Patent Application No. 61 / 393,313 entitled "User-Defined Electronic Trading Algorithm", US Non-Temporary Patent Application No. 12 / 905,709 and 2010 entitled "User-Defined Electronic Trading Algorithm" filed October 15, 2010. It claims the benefit of the US non-provisional patent application No. 12 / 905,726, entitled "Virtualization of User-Defined Electronic Trading Algorithms," filed October 15. Each of these applications is included in the disclosure in its entirety by this reference.
The techniques described herein relate to electronic trading systems. More specifically, certain embodiments relate to user-defined electronic trading algorithms.
Electronic trading systems generally include client devices that communicate with electronic exchanges that can act as hosts for client devices. Typically, an electronic trading system attempts to trade electronically matched orders that buy and sell tradable objects. A tradable object is an item that can be traded. Stocks, options, futures contracts, securities and commodities are some examples of tradable objects.
The electronic exchange sends market data to the client device. Market data may include, for example, price data, market depth data, final trading volume data, market-related data for tradable objects and / or combinations thereof. The client device receives market data from the electronic exchange.
Depending on the electronic trading system, the client device receives the market data and processes the market data without displaying it on the display device. For example, a "black box" algorithmic trading system may be executed automatically and without displaying market data. However, in other electronic trading systems, the client device displays the market data being processed on the display device. The client device may include software that creates the transaction screen. In general, trading screens allow users to participate in electronic trading sessions. For example, trading screens allow users to view market data, place trading orders on electronic exchanges, obtain market quotes, monitor positions, and / or combine them. In some cases.
Depending on the electronic trading system, the client device sends a trading order to the electronic exchange. However, in other electronic trading sessions, other devices, such as server-side devices, are responsible for sending one or more trading orders to the electronic exchange. Upon receiving a trade order, the electronic exchange fills the exchange order book with the trade order and attempts to match the volume of the trade order with the volume of one or more counterparty trade orders. As an example, a sell order is the other party to a buy order of the same amount. Similarly, a buy order is the other party to a sell order of the same amount. Inconsistent trading order volumes are held in the exchange order book by the electronic exchange until the trading order volumes are matched. Inconsistent trading order volumes may also be excluded from the order book if the trading order is canceled by either the client device or the electronic exchange. Once the transaction volume has been matched, the electronic exchange may send a confirmation to the client device that the transaction volume has been matched.
Electronic exchanges allow an increasing number of participants to operate in the market at any given time. The increase in potential market participants has effectively resulted in more competitive markets and greater asset liquidity, among other things. Help participants compete effectively in the market in competitive environments, such as e-commerce, where every second or a fraction of a second is important to get a trading opportunity. , Or it is desirable to provide tools that also give participants an edge over others.
Some current systems include algorithmic trading systems that enable faster assessment and response to changes in market information. However, such systems typically require skilled programmers to develop trading algorithms, take days (or months) to test and debug, and traders decide on different approaches, or This development and debugging process must be repeated if an algorithmic logic modification is desired.
<p> The embodiments described herein include, but are not limited to, various devices, systems, methods and computer program products.</p>
<p> Certain embodiments provide a building block button and an algorithm area that defines the algorithm. Certain embodiments are expected to rapidly adjust both the parameters and logic of the algorithm, even during a single trading session. A given embodiment provides a live evaluation of the equation as the algorithm is defined. In certain embodiments, the user writes programming code at the risk of a traditionally programmed algorithm, such as syntax errors, ambiguous logic, and the need for a non-trader programmer to develop the algorithm as specified by the trader. Reduce by reducing or eliminating. A given embodiment provides a single application for building algorithms, debugging and simulating (using real market data) all at the same time. In addition, this single application may also prepare for the initiation of an algorithmic order.</p><p> Certain embodiments provide design canvas areas and blocks for designing algorithms. Certain embodiments provide blocks with complex functions for use in algorithms. A predetermined embodiment provides for grouping a plurality of blocks placed within a design canvas area. A given embodiment prepares a virtualized group block that allows some dynamic instantiation of the algorithm to handle certain discontinuous events. Certain embodiments are expected to rapidly adjust both the parameters and logic of the algorithm, even during a single trading session. Certain embodiments provide live feedback of blocks as the algorithm is defined. Certain embodiments provide safety features to reduce potential errors when the algorithm is designed. A predetermined embodiment prepares the operation of some or all parts of the algorithm when the connection between the client device and the algorithm server is broken. In certain embodiments, the user writes programming code at the risk of a traditionally programmed algorithm, such as syntax errors, ambiguous logic, and the need for a non-trader programmer to develop the algorithm as specified by the trader. Reduce by reducing or eliminating. A given embodiment provides a single application for building algorithms, debugging and simulating (using real market data) all at the same time. In addition, this single application may also prepare for the initiation of an algorithmic order.</p><p> A predetermined embodiment prepares for the initiation of an order to be managed as an order type by the selected algorithm. A predetermined embodiment prepares for the initiation of an order to be managed by a user-defined trading algorithm selected from the price axis. A predetermined embodiment prepares for changing the variables of the algorithm while the algorithm manages an order. A predetermined embodiment prepares for manually modifying an order managed by an algorithm. A predetermined embodiment provides for assigning an algorithm to manage an unmanaged order to that order. A predetermined embodiment provides for displaying on the price axis the accepting orders managed by different user-defined trading algorithms.</p><p> A predetermined embodiment provides a ranking tool. A predetermined embodiment prepares a ranking display of selected tradable objects to be used for ordering. A predetermined embodiment prepares for selecting an execution strategy for initiating an order on the basis of ranking.</p><p> Hereinafter, other embodiments will be described. Moreover, the embodiments described may be modified without departing from the spirit or scope of the invention.</p>
In the present specification, examples of embodiments will be described with reference to the following drawings.
<figref num="1">It is a block diagram which shows the electronic trading system in which a predetermined embodiment can be used.</figref>
<figref num="2A">A trading interface according to a predetermined embodiment is shown.</figref>
<figref num="2B">An instrument selection interface according to a predetermined embodiment is shown.</figref>
<figref num="2C">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2D">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2E">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2F">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2G">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2H">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref><figref num="2I">The construction of the algorithm definition in the trading interface according to a predetermined embodiment is shown.</figref>
<figref num="2J">A trading interface according to a predetermined embodiment is shown.</figref>
<figref num="3A">It is a block diagram which shows the electronic trading system in which a predetermined embodiment can be used.</figref>
<figref num="3B">A trading interface according to a predetermined embodiment is shown.</figref>
<figref num="3C">An example of a block that can be used in a trading interface according to a given embodiment is shown.</figref>
<figref num="3D-1">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-2">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-3">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-4">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-5">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-6">An example of programming code generated by a given embodiment is shown.</figref><figref num="3D-7">An example of programming code generated by a given embodiment is shown.</figref>
<figref num="3E">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3F">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3G">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3H">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3I">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3J">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3K">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3L">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3M">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3N">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3O">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3P">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3Q">A trading interface according to a predetermined embodiment is shown.</figref><figref num="3R">A trading interface according to a predetermined embodiment is shown.</figref>
<figref num="4A">A trading interface according to a predetermined embodiment is shown.</figref><figref num="4B">A trading interface according to a predetermined embodiment is shown.</figref><figref num="4C">A trading interface according to a predetermined embodiment is shown.</figref><figref num="4D">A trading interface according to a predetermined embodiment is shown.</figref><figref num="4E">A trading interface according to a predetermined embodiment is shown.</figref><figref num="4F">A trading interface according to a predetermined embodiment is shown.</figref>
<figref num="5">A ranking tool according to a predetermined embodiment is shown.</figref>
<figref num="6">It is a block diagram which shows the computing device by a predetermined embodiment.</figref>
The outline of the invention described above and the detailed description below will be better understood by reading in connection with the figures showing a given embodiment. It should be understood that the drawings are for illustration of certain embodiments and the present invention is not limited to the arrangements and means shown in the drawings.
I. Example of electronic trading system
FIG. 1 is a block diagram showing an electronic trading system 100 in which a predetermined embodiment can be used. System 100 includes a client device 110, a gateway 120, and an electronic exchange 130. The client device 110 is communicating with the gateway 120. The gateway 120 communicates with the electronic exchange 130.
The phrase "communicating with" herein may include direct communication and indirect communication via one or more intermediate components.
During operation, client device 110 may send an order to exchange 130 to buy or sell tradable objects. For example, the user may use the client device 110 to send an order. Orders are sent to exchange 130 via gateway 120. In addition, market data is sent from exchange 130 to client device 110 via gateway 120. The user may also use the client device 110 to monitor this market data and decide to send orders for tradable objects based on the market data.
A tradable object is any object that can be traded in a certain quantity and / or price. For example, financial instruments such as stocks, options, bonds, futures, currencies, warrants, fund derivatives, securities, commodities, traded events, goods and collections and / or combinations thereof may be tradable objects. The tradable object may be a "real thing" or a "composite". Real tradable objects include the goods listed by the exchange. A tradable object that is a composite includes goods that are defined by the user and not listed by the exchange. For example, a tradable object that is a composite may include a combination of real (or other synthetic) commodities such as synthetic spreads created by a trader utilizing the client device 110.
Client device 110 includes one or more electronic computers such as portable devices, laptops, desktop computers, workstations with single or multi-core processors, servers with multiple processors and / or clusters of computers. A wing platform may be included. For example, the client device 110 is logically represented as a single device, but may include a trading terminal that communicates with a server, wherein the trading terminal and the server are collectively the client device 110. The transaction terminal may present the transaction screen to the user, and may transmit a command related to further processing of user input such as an order via the transaction screen to the server.
The client device 110 is generally owned, manipulated, controlled, programmed, configured, or used separately by the user. As used herein, the term "user" may include, but is not limited to, a person (eg, a trader) or an electronic trading device (eg, including a processor and memory or an algorithmic trading system). One or more users may be, for example, related to ownership, operation, control, programming, configuration or other uses.
Client device 110 may include one or more trading applications. The trading application may process the market data, for example, by arranging the market data and displaying it in the trading window and the chart window. Market data may be received, for example, from exchange 130. As another example, market data may be received from a simulation environment that provides historical data and / or simulates exchanges but does not perform real-world transactions. This process may be based on user preference, for example. The trading application may include, for example, an automated trading tool such as an automated spread trading tool. The trading application may be distributed to one or more of the computing devices of the client device 110. For example, a given component of a trading application may run on a trading workstation, and other components of the trading application may run on a server that communicates with the workstation.
The client device 110 may include, for example, an electronic trading workstation, a portable trading device, an algorithmic trading system such as a "black box" or "gray box", a built-in trading system and / or an automated trading tool. For example, the client device 110 may be a computing system that performs a copy of X_TRADER®, an electronic trading platform provided by Trading Technologies International, Inc., located in Chicago, Illinois. As another example, the client device 110 may be a computing device that runs an automated trading tool such as Autospreader® and / or Autotrader®, also provided by Trading Technologies International.
The trading application may be stored on a computer-readable medium on the client device 110. In certain embodiments, certain components of the trading application may be stored on the trading workstation, and other components of the trading application may be stored on the server communicating with the workstation. In certain embodiments, one or more components of the trading application may be loaded from another computer readable medium into the computer readable medium of the client device 110. For example, the trading application (or update of the trading application) may be stored on one or more CDs or DVDs by the manufacturer, developer or issuer, which CDs or DVDs are then sent to the client device 110. It is provided to someone responsible for loading the application, or to the server to which the client device 110 searches for trading applications. As another example, the client device 110 may receive a trading application (or update of a trading application) from a server, for example via the Internet or an internal network. The client device 110 may receive the trading application or update as requested by the client device 110 ("pull delivery") or may not be requested by the client device 110 ("push delivery"). is there.
Client device 110 is adapted to send buy or sell orders for tradable objects. The client device 110 may also be adapted, for example, to cancel the order, modify the order and / or query the exchange. As another example, the client device 110 may be adapted to send an order to a simulated exchange in a simulated environment that does not perform real-world transactions.
The order sent by the client device 110 may, for example, be requested and sent by the user, or may be sent automatically. For example, a trader may use an electronic trading workstation to place an order for a particular tradable object and manually provide various parameters for that order, such as the price and / or quantity of the order. As another example, the automated trading tool may calculate one or more parameters for an order and automatically submit the order. Depending on the instance, the automated trading tool may prepare an order to be submitted, but it will not actually submit it without confirmation from the user.
In certain embodiments, the client device 110 includes a user interface. The user interface may include, for example, one or more display devices for presenting the user with a text-based or graphical interface of the trading application. For example, display devices may include computer monitors, handheld device displays, projectors and / or televisions. The user interface may be used by the user to specify or review parameters related to the order using the trading application. The user interface may include, for example, one or more input devices for receiving input from the user. For example, input devices may include a keyboard, trackball, two or three button mouse and / or touch screen. The user interface may include other devices for interacting with the user. For example, the information may be audibly provided to the user via a speaker and / or received via a microphone.
In certain embodiments, the trading application may include one or more trading screens that allow the trader to interact with one or more markets. Trading screens allow, for example, traders to obtain and view market information, set order entry parameters, place and cancel orders, and / or monitor positions while implementing various trading strategies. May be good. For example, a trading application may receive information from exchange 130 such as bid price, bid quantity, bid price, sell quantity, price and quantity of past sales and / or other market-related information. The information may then be displayed by the user interface of the client device 110. Based on the information received, the trading screen may display a range of price levels for tradable objects and the corresponding trading volume of those price levels. To provide the trader with relevant trading information, the trading screen may display a price range (and corresponding trading volume) around the on-site market. The information may be provided to the trading application constantly or on a regular basis, which allows the trading application to update the trading screen with the current market information. The trader may, for example, place a buy order and a sell order for the tradable object using the trading screen, or may separately trade the tradable object based on the displayed information.
The trading screen may display one or more trading tools. A trading tool is an electronic tool that enables, assists, and / or facilitates electronic trading. Illustrative trading tools include charts, trading ladders, order entry tools, automated trading tools, automated spread tools, risk management tools, order parameter tools, order entry systems, market grids, fill windows and market order windows, combinations of these. Includes, but is not limited to, other electronic tools used to trade, prepare trades or manage trades.
In certain embodiments, the client device 110 comprises an algorithmic trading application. For example, client device 110 may include a black box or gray box trading application. As another example, the client device 110 processes market data algorithmically, but allows the user to manually place orders on the basis of algorithmic processing or to manipulate automatically placed orders. It may include a trading application that provides a user interface. An algorithmic trading application is a trading application that includes an algorithm that is automatically processed to perform a given action. That is, the trading application contains a set of automated instructions to perform a defined action. Actions select, for example, to process market data in a particular way, place an order, modify an existing order, delete an order, refrain from placing an order, or which tradable object to act on. To determine the order price or the modified order price, to determine the quantity to order or the quantity to modify the order, to determine whether the order should be a buy order or a sell order, and to take action. It may include delaying for a certain period of time.
As used herein, an algorithm (also referred to as a trading algorithm) is specified by a definition that includes a formula and parameters that describe the algorithm to be used in the transaction. A logical expression specifies the relationship between parameters and may generate additional parameters. The parameters may include, for example, inputs to the logical expression of the algorithm. The definition of the algorithm may be specified at least partially by the algorithmic trading application. For example, an algorithmic trading application may allow the user to specify the parameters to be used only by a predefined formula. As another example, an algorithmic trading application may allow the user to specify some or all of the formulas and some or all of the parameters. The trading algorithm whose formula is specified by the user is a user-defined trading algorithm.
In certain embodiments, the order from the client device 110 is sent to the exchange 130 via the gateway 120. The client device 110 may communicate with the gateway 120 using, for example, a local area network, a wide area network, a virtual private network, a Tl line, a T3 line, an ISDN line, a point of presence and / or the Internet.
Gateway 120 is adapted to communicate with client device 110 and exchange 130. The gateway 120 facilitates communication between the client device 110 and the exchange 130. For example, gateway 120 may receive an order from client device 110 and send this order to exchange 130. As another example, gateway 120 may receive market data from exchange 130 and transmit this market data to client device 110.
In certain embodiments, the gateway 120 performs processing of data that is communicated between the client device 110 and the exchange 130. For example, gateway 120 may process orders received from client device 110 into a data format acceptable by exchange 130. Similarly, gateway 120 may convert exchange-specific format market data received from exchange 130 into a format understood by client device 110. The processing by the gateway 120 may also include, for example, tracking the order from the client device 110 and updating the status of the order based on the execution confirmation received from the exchange 130. As another example, gateway 120 may fuse market data from exchange 130 and provide it to client device 120.
In certain embodiments, the gateway 120 provides services other than the processing of data communicated between the client device 110 and the exchange 130. For example, gateway 120 may provide risk handling.
Gateway 120 includes one or more electronic computing such as, for example, portable devices, laptops, desktop computers, workstations with single or multi-core processors, servers with multiple processors and / or clusters of computers. The platform may be included.
Gateway 120 may include one or more gateway applications. The gateway application may handle, for example, the processing of orders and the processing of market data. This process may be based on user preference, for example.
In certain embodiments, the gateway 120 communicates with the exchange 130 using, for example, a local area network, a wide area network, a virtual private network, a Tl line, a T3 line, an ISDN line, a point of presence and / or the Internet. You may.
In general, Exchange 130 may be owned, manipulated, controlled, or used by a trading entity. Illustrative trading entities include CME Group, London International Financial Futures Options Exchange ("LIFFE"), Intercontinental Exchange ("ICE") and Eureks. Exchange 130 is an electronic matching system such as a computer, server, or other computing device adapted to buy or sell, for example, tradable objects offered for trading by the exchange. May be good.
Exchange 130 is adapted to align buy and sell orders for tradable objects. The tradable object may be listed for trading by exchange 130. The order may include, for example, an order received from the client device 110. The order may be received, for example, from the client device 110 via the gateway 120. In addition, orders may be received from other devices that communicate with exchange 130. That is, typically, exchange 130 communicates with various other client devices (which may be similar to client device 110) that also offer orders to be matched.
Exchange 130 is adapted to provide market data. Market data may be provided, for example, to client device 110. Market data may be provided to the client device 110, eg, via gateway 120. The market data may include, for example, data representing the on-site market. The on-site market is the cheapest ask price (also called the "lowest limit price") and the highest buy price (also called the "highest limit price") at a particular point in time. Market data may also include market depth. Market depth refers to the quantity available in the on-site market and may also refer to the quantity available at other prices outside the on-site market. Therefore, the on-site market may be the depth level of the first market. One tick outside the on-site market may be, for example, the depth level of the second market. In certain embodiments, the depth of the market is defined for all price levels. In certain embodiments, market depth is not defined for all price levels. For example, the depth of the market may be defined only for the first five price levels inside and outside the on-site market. The depth of the market may also include information such as final trading price (LTP), final trading volume (LTQ) and order execution information.
In certain embodiments, system 100 includes two or more client devices 110. For example, a plurality of client devices similar to the client device 110 discussed above may be communicating with the gateway 120 to send an order to exchange 130.
In certain embodiments, system 100 includes two or more gateways 120. For example, a plurality of gateways similar to the gateway 120 discussed above may communicate with the client device 110 and the exchange 130. Such an arrangement may be used, for example, to provide redundancy in the event of a gateway 120 failure.
In certain embodiments, system 100 includes two or more exchanges 130. For example, the gateway 120 may communicate with a plurality of exchanges similar to the exchange 130 discussed above. Such an arrangement may allow, for example, the client device 110 to trade through the gateway 120 on two or more exchanges.
In certain embodiments, system 100 includes two or more exchanges 130 and two or more gateways 120. For example, a plurality of gateways similar to the gateway 120 discussed above may communicate with a plurality of exchanges similar to the exchange 130 discussed above. Each gateway may communicate with, for example, one or more different exchanges. Such an arrangement may, for example, allow one or more client devices 110 to trade on more than one exchange (and / or provide redundant connections to multiple exchanges). Good.
In certain embodiments, the client device 110 comprises one or more computing devices or processing components. In other words, the functionality of client device 110 may be performed by more than one computing device. For example, one computing device may generate an order to be sent to exchange 130, while another computing device may provide a graphical user interface to the trader. In certain embodiments, the gateway 120 comprises one or more computing devices or processing components. In other words, the function of gateway 120 may be performed by two or more computing devices. In certain embodiments, exchange 130 includes one or more computing devices or processing components. In other words, the functions of Exchange 130 may be performed by more than one computing device.
In certain embodiments, the gateway 120 is part of the client device 110. For example, the components of gateway 120 may be part of the same computing platform as client device 110. As another example, the function of gateway 120 may be performed by a component of client device 110. In certain embodiments, the gateway 120 is absent. Such an arrangement is adapted so that, for example, the client device 110 does not need to utilize the gateway 120 to communicate with the exchange 130, for example, the client device 110 communicates directly with the exchange 130. In some cases, it may occur.
In certain embodiments, the gateway 120 is physically co-located with the client device 110. In certain embodiments, the gateway 120 is physically positioned at the same location as the exchange 130. In certain embodiments, the client device 110 is physically positioned at the same location as the exchange 130. In certain embodiments, the gateway 120 is physically positioned at a location separated from both the client device 110 and the exchange 130.
Although not shown for clarity, in certain embodiments, System 100 also includes middleware, firewalls, hubs, switches, routers, exchange-specific communications equipment, modems, security managers and / or encryption /. It may include devices specific to the communication architecture, such as decryption devices.
The system 100 components, elements and / or functions discussed above may be implemented alone or in combination in various forms, eg, as an instruction set in hardware, firmware and / or software. Certain embodiments are provided as an instruction set that resides on a computer-readable medium such as memory, a hard disk, a CD-ROM, a DVD, an EPROM, and / or a file server for execution on a general purpose computer or other processing device. You may. II. Algorithm Order Builder
Certain embodiments provide a building block button and an algorithm area that defines the algorithm. Certain embodiments are expected to rapidly adjust both the parameters and logic of the algorithm, even during a single trading session. A given embodiment provides a live evaluation of the equation as the algorithm is defined. In certain embodiments, the user writes programming code at the risk of a traditionally programmed algorithm, such as syntax errors, ambiguous logic, and the need for a non-trader programmer to develop the algorithm as specified by the trader. Reduce by reducing or eliminating. A given embodiment provides a single application for building algorithms, debugging and simulating (using real market data) all at the same time. In addition, this single application may also prepare for the initiation of an algorithmic order.
FIG. 2A shows a trading interface 200 according to a predetermined embodiment. The trading interface 200 is a trading interface for an algorithmic trading application called an algorithmic order builder ("AOB"). The AOB allows the trader to generate an algorithm for the order to be placed. However, it should be understood that the elements of the illustrated trading interface 200 may be incorporated into other trading interfaces.
The trading interface 200 includes an instrument selection button 201, a market grid 202, a simulated reference order input area 203, an auto-hedging option 204, a scratch amount 205, a variable area 206, and an algorithm area 210. And the building block button 215. Algorithm area 210 includes price area 211, quantity area 212, and conditional area 213.
During operation, the algorithm is defined in algorithm area 210 by constructing expressions in price area 211, quantity area 212 and / or conditional area 213 using one or more building block buttons 215. .. Default values for user-defined variables in the algorithm may be specified using variable area 206. Once the algorithm is defined, the simulated reference order input area 203 may be used to display how the logic of the expression behaves. The trading interface may then be used to initiate orders that should be managed according to a defined algorithm.
The instrument selection button 201 prepares the selection of the instrument (ie, tradable object) associated with the order to be placed. As shown in Figure 2A, the instrument selection button 201 already selects the GEH1-GEM1 calendar spread, as the name of the selected instrument is displayed on the instrument selection button 201. Is being used. If the instrument is not already selected, the instrument selection button 201 may display "Select instrument" or give some other indication that the instrument is not yet selected. ..
When the instrument selection button 201 is activated (for example, by selecting with a pointer or by touching the touch screen), an instrument selection interface is displayed that allows the instrument to be selected. May be good.
FIG. 2B shows an instrument selection interface 220 according to a predetermined embodiment. The instrument selection interface 220 displays a list of tradable commodities and allows the user to specify specific tradable objects to be traded by following the instrument tree. The instrument tree allows the user to select, for example, an instrument, a type of instrument (eg, a spread or futures) and a particular contract to be displayed. For example, the GEH1-GEM1 calendar spread is selected as shown.
With reference to FIG. 2A again, the market grid 202 displays market information for a tradable object. The tradable object may be, for example, the instrument selected with the instrument selection button 201. As another example, the tradable object may be another tradable object of your choice. The market grid 202 may display, for example, buy and / or sell bids, buy and / or sell quantities, final transaction prices and / or quantity information for tradable objects. For example, the market grid 202 may display the on-site market price and quantity of the selected instrument.
The simulated reference order input area 203 provides for the generation of feedback to evaluate the operational aspects of the algorithm defined in algorithm area 210. The user may simulate buying and selling selected instruments using the simulated reference order input area 203 to display how the logic of the expression behaves. .. The price and / or quantity of the virtual order may also be specified using the reference order input area 203, which is also simulated. Further, in certain embodiments, the simulated reference order input area 203 executes the actual order to buy or sell the selected instrument (eg, when the order is managed according to a defined algorithm). , May be set to start (by selecting the checkbox).
Auto-hedging option 204 is prepared to specify that a counter-order will be placed when the opened order is filled. The counter-order is a sell order if the filled order is a buy order, and a buy order if the filled order is a sell order. The quantity of the counterorder may be, for example, the same as the contracted quantity. The counter-order is first placed at a profitable exit price, for example, one increment (as specified by the exchange) that can be traded from the price of the executed order. For example, if the executed order buys a quantity of 10 at a price of 100, the counter-order may be an order that sells a quantity of 10 at a price of 101. As another example, if the filled order sells quantity 5 at price 100, the counter-order may be an order to buy quantity 5 at price 99.
The scratch amount 205 is used by the auto-hedging option 204. When the quantity at the price level of the counterorder in the market falls below the specified scratch quantity 205, the price level of the counterorder is changed to the price of the corresponding filled order. In this case, the filled order is said to be "scratched" and the transaction is not profitable. In certain embodiments, the counter-order may be placed at a price that closes the position regardless of profit or loss.
Variable area 206 provides for specifying and modifying user-defined variables used in algorithm area 210. The variable area 206 displays the name of each variable and its value. The variable area may be selected to change the name of the variable and / or its value. Variables are sometimes referred to as algorithm parameters.
Algorithm area 210 provides for defining algorithms for managing orders. Algorithm area 210 includes price area 211, quantity area 212, and conditional area 213. Each area corresponds to a different aspect of the algorithm.
The building block button 215 is used to build an expression in algorithm area 210 to define the algorithm. The equation is evaluated to determine the value of each area of algorithm area 210. The expression contains one or more elements specified by the building block button 215. The use of the building block button 215 will be described in more detail below.
Once the algorithm is defined in the algorithm area 210, the trading interface may initiate a buy or sell order. For example, in addition to preparing to initiate a virtual order, in certain embodiments, the simulated reference order input area 203 may also be prepared to initiate an actual order. As another example, a trading interface similar to that described below may be used to initiate an order. The initiated order is then managed according to the defined algorithm.
Price area 211 is evaluated to determine the order price of managed orders. Price area 211 evaluates a number representing the price. If the price area 211 is blank, the price specified in the simulated reference order input area 203 is used. If the price area 211 contains an expression, the price specified in the simulated reference order input area 203 may be ignored. Price area 211 may evaluate different values at different times, such as when market data changes. If so, the managed order will be modified to be accepted at the new price. This may be achieved, for example, by deleting the order and placing a new order at a new price, or by using a cancel / replace command.
The quantity area 212 is evaluated to determine the order quantity of the managed order. The quantity area 212 evaluates a number representing the quantity. If the quantity area 212 is blank, the quantity specified in the simulated reference order entry area 203 is used. If the quantity area 212 contains an expression, the quantity specified in the simulated reference order input area 203 may be ignored. The quantity area 212 may evaluate different values at different times, such as when market data changes. If so, the managed order will be modified to be accepted in the new quantity. This may be achieved, for example, by deleting the order and placing a new order with a new quantity, or by using the order quantity change command. If the quantity area 212 evaluates 0, the managed order may be removed from the market until the quantity area 212 evaluates a non-zero value. This may be similar to the conditional area 213 evaluating "false", as described below.
In certain embodiments, the algorithm area 210 does not include the quantity area 212. Instead, the quantity may be constant or predefined. For example, a trading interface for managing hedge orders (a hedge order is, for example, an order that is automatically placed when another order for a tradable object in a trading strategy is filled, which is the hedge manager. (Sometimes also referred to as an interface) is based on the executed quantity of other orders, and may therefore use a predetermined quantity from an algorithmic point of view. Therefore, the algorithm area in such a trading interface, which may allow the algorithm to be used to make the hedge order work, does not need to be specified as the quantity value is predetermined at the time the algorithm is used. The quantity area 212 may not be included for reasons.
Conditional area 213 is evaluated to determine if the algorithm should work. Conditional area 213 evaluates a Boolean value. If the conditional area 213 evaluates to "true", then the algorithm is working. If conditional area 213 evaluates to "false", then the algorithm is not working. If the conditional area 213 is blank, the algorithm is always working. Conditional area 213 may evaluate different values at different times, such as when market data changes. If the algorithm is working, the managed orders are entered into the market and, as discussed above, are worked by the determined price and quantity. If the algorithm is not working, the managed order will be removed from the market. This may be achieved, for example, by deleting the order.
In certain embodiments, the algorithm area 210 does not include the conditional area 213. Alternatively, the algorithm may simply be "working" at all times once the order is initiated. For example, in the hedge manager interface, algorithms that manage hedge orders may always be working, as it may be desirable for hedge orders to be filled as quickly as possible.
The value evaluated by the expression in price area 211, quantity area 212 and / or conditional area 213 must be of the appropriate type (price area 211, number for order quantity area 212, Boolean value for conditional area 213). If so, the expression is invalid. The background of a particular area may be changed from green (indicating a valid expression) to red (indicating an invalid expression) to indicate that the expression is invalid. If the expression is invalid in one of the areas of the algorithm area 210, the order cannot be placed.
In certain embodiments, in addition to (or in addition to) the background color, other indicators may be used to indicate that the expression in the area of algorithm area 210 is invalid. For example, different background patterns, different border colors or styles, text messages such as "ready" or "invalid" and / or exclamation mark icons may be used.
Once the orders managed according to the algorithm are filled, counter-orders may be automatically placed on the basis of auto-hedging option 204 and scratch volume 205, as discussed above.
As discussed earlier, the building block button 215 is used to build an expression in algorithm area 210 to define the algorithm. The building block button 215 may also be referred to as, for example, an icon, a movable icon, an icon button, a movable button or a user interface element. Expressions contain elements (formulas and parameters) and are evaluated to determine the value of each area of algorithm area 210. The building block button 215 may be selected to construct an expression and placed in a specific area of algorithm area 210. For example, the user drags one or more building block buttons 215 into one or more of the areas of algorithm area 210 such as price area 211, quantity area 212 and / or conditional area 213. You may drop it. As another example, the user may select the building block button 215, for example by clicking on it, and the selected button 215 may then be placed in the recently used algorithm area 210. Good. When the building block button 215 is placed in the algorithm area 210, the elements are placed in the expression constructed in the algorithm area 210. As will be described later, certain elements in the equation may include additional elements that act as, for example, subexpressions.
Types of building block button 215 include instruments, constants, arithmetic operators, logical operators, operator precedence, if-then-else configurations and variables. The building block button of an instrument specifies attributes of the selected instrument, such as bid price and sell quantity. The fixed value building block button specifies, for example, constant numbers and Boolean values. Arithmetic operator building block buttons include arithmetic operations such as addition ("+"), subtraction ("-"), multiplication ("*") and division ("/"). In addition, the building block button of the arithmetic operator may include an orderer-specific arithmetic operation such as ("+/-"), which is an addition for buy orders and a subtraction for sell orders. Yes (or, as you specify, add for sell orders and subtract for buy orders). Logical operator building block buttons are, for example, logical operations such as AND, OR and NOT, and greater than (">"), less than ("<"), greater than or equal to ("> ="), and less. Includes comparisons such as ("<=") and equal sign ("="). In addition, the logical operator building block button is "> / < It may include an orderer-specific logical operation such as ", which is greater for buy orders and less for sell orders (or, as the user specifies, for sell orders). Greater and lesser when it comes to buy orders). Operator precedence building block buttons contain parentheses ("(" and ")"). In certain embodiments, operator precedence building block buttons may be used to form subexpressions consisting of the elements in parentheses. Building block buttons in the if-then-else configuration expect to specify conditional values, for example. A building block button in an if-then-else configuration provides a part where a partial expression can be constructed using one or more elements. The variable building block button specifies, for example, a user-defined variable whose value may have been changed using variable area 206, as discussed earlier.
FIG. 2C-FIG. 2I shows the construction of an algorithm definition at trading interface 200 according to a given embodiment.
As shown in Figure 2C, the instrument building block button 231 is selected and placed in price area 211 as the instrument building block 232. The instrument building block 232 allows the user to select from Listing 233 which attribute of the selected instrument should be used. The bid price for the instrument has already been selected. Therefore, the price area 211, which includes the building block 232 of the instrument (designated as the bid price of the instrument), evaluates the momentary bid price of the instrument in the market.
Examples of selected instrument attributes are Buy Bid, Sell Bid, Buy Quantity, Sell Quantity, Final Trading Price, Final Trading Volume, Volume, Trading Session High, Trading Session Low, Implicit Sell / Buy Quantity. Includes (also known as actual sell / buy quantity), checkout value, minimum tradable increment (also known as tick size) and number of orders in the queue at a price (also known as headcount) .. In addition, special order-specific attributes such as "buy bid *", "sell bid *", "buy quantity *", and "sell quantity *" may also be specified (not shown). For these special attributes, the specified value is used for buy orders and the opposite of the specified value is used for sell orders. For example, if "sell bid *" is selected, the formula evaluates the sell bid of the buy order and the buy bid of the sell order.
As shown in Figure 2D, the subtraction arithmetic operator building block button 241 is selected and placed in price area 211 as the subtraction building block 242. The formula in price area 211 now contains the instrument building block 232 and the subtraction building block 242.
However, the expression in price area 211 is invalid at this point and therefore cannot be evaluated (the "buy bid,-" is syntactically meaningless). This may be treated in the same way as an invalid area type, as discussed earlier. That is, since the expression in the price area 211 is invalid, the background of the price area 211 is changed from green (indicating a valid expression) to red (indicating an invalid expression).
As shown in Figure 2E, the constant value building block button 251 is selected and placed in price area 211 as the fixed value building block 252. The user has specified that the fixed value building block 252 should have the value "0.5". The formula in price area 211 is now valid again (note that the background has changed from red to green) and evaluates the momentary bid price of the minus 0.5 instrument.
As shown in FIG. 2F, the if-then-else configuration building block button 261 is selected and placed in the quantity area 212 as an if-then-else configuration building block 262. The building block 262 in the if-then-else configuration includes an IF portion 263, a THEN portion 264, and an ELSE portion 265. Subexpressions of one or more elements (including nested if-then-else building blocks) may be constructed in each part of if-then-else building block 262. When building block 262 with an if-then-else configuration is evaluated, its value is determined as follows. IF part 263 is evaluated to determine the Boolean value. If the determined Boolean value from IF part 263 evaluates to "true", building block 262 in the if-then-else configuration evaluates the value of the expression in THEN part 264. If the determined Boolean value from IF part 263 evaluates to "false", building block 262 of the if-then-else configuration evaluates the value of the expression in ELSE part 265.
The building block button 215 is also used to construct an expression in the building block 262 part of the if-then-else configuration. As shown, IF portion 263 contains a partially constructed equation to make a comparison that determines if the buy quantity of the instrument is greater than something. However, this expression is invalid because it does not make syntactically meaningful. Inevitably, to display this, note that the background of IF part 263 is red, not green. Moreover, the building block 262 in the if-then-else configuration is not valid (because its IF portion 263 is not valid), and the expression in the quantity area 212 is not valid, and thus also has a red background.
As shown in FIG. 2G, the building block 262 in the if-then-else configuration already contains a valid formula in each of its parts, and thus the formula in quantity area 212 is also valid.
Building blocks in an if-then-else configuration may be nested, as shown in Figure 2H. The ELSE portion 265 of the building block 262 in the if-then-else configuration contains another building block 266 in the if-then-else configuration. As shown, the building block 266 with an if-then-else configuration cannot be evaluated because it does not contain an expression in any of its parts, and thus the building with an if-then-else configuration. An invalid expression in ELSE part 265 of block 262. Inevitably, ELSE part 265 has a red background indicating that the expression is invalid. Furthermore, since the ELSE part 265 has an invalid expression, the building block 262 in the if-then-else configuration does not have a valid expression, so the background of the quantity area 212 is red.
As shown in FIG. 2I, the expression in IF portion 263 of building block 262 in an if-then-else configuration includes variable building blocks 273, 274, 275 and 276. The variable building blocks 273, 274, 275 and 276 have an option to indicate that the constant value must be a variable by using the variable building block button or when using the fixed value building block button. It may be arranged by selection. The variable building block 273 displays the variable name ("M_TH_1") and its value ("5000"). This may represent, for example, the minimum threshold. As discussed earlier, variable area 206 displays each variable name and its value. As shown, the variable area 206 has a name column 271 with inputs for each of the variable building blocks 273, 274, 275 and 276, and a default value column 272 with a corresponding default value input for each variable. Including. The user can change the default value for individual variable building blocks by selecting the default value input in the default value column 272, so that the evaluation of the expression in quantity area 212 will use that new default value. Similarly, the user can rename individual variable building blocks by selecting the name input in name column 271. The variable building blocks 273, 274, 275 and 276 may allow the user to manipulate the behavior of the algorithm rather than the underlying logic, for example by changing the value of the variable acting as a parameter of the algorithm.
The trading interface 200 provides a live evaluation function. The live evaluation function provides a display of the evaluation value of an expression, as shown in Figure 2C-Figure 2I. The live evaluation value may be provided, for example, as a defined algorithm. The live evaluation value may be displayed, for example, in relation to the expression being evaluated. The evaluation may be performed each time the expression changes, or each time the value of the building block in the expression changes. Evaluations may also be performed periodically or constantly. In certain embodiments, live evaluation values may be provided with respect to the partial formula. In certain embodiments, live evaluation values may be provided for individual elements of the expression.
As shown in Figure 2C, the bid price of the instrument is selected as an attribute of the instrument building block 232 as discussed earlier. The live rating 281 of price area 211 shows "8.5", which is the current bid for the instrument (also shown in Market Grid 202). As shown in Figure 2D, the formula in price area 211 is invalid as discussed earlier, so the live rating is not displayed because the formula cannot be evaluated. As shown in Figure 2E, the live rating 282 in price area 211 shows an "8", which is the instrument's bid price (8.5) minus the fixed price (0.5). is there.
In addition to live evaluations of price area 211, quantity area 212 and conditional area 213, live evaluations may also be performed on expressions within these areas. For example, as shown in Figure 2G, live evaluation is provided for each part of the building block 262 in an if-then-else configuration, as well as for the quantity area 212 itself. The live rating 283 of the IF part 263 is "true" because the instrument buy quantity (863) is 60 or more. The live rating 284 of THEN part 264 is 2 because the expression in THEN part 264 is simply a fixed value 2. Similarly, the live rating 285 of the ELSE part 265 is 1 because the expression in the ELSE part 265 is simply a constant value 1. Therefore, the live evaluation 286 of the quantity area 212 is "2", which is because the evaluation of the IF part 263 is "true", so the evaluation of the building block 262 of the if-then-else configuration is the THEN part 264. This is because it becomes a value.
The building block button 215 and algorithm area 210 of the trading interface 200 allow users such as traders or non-programmers to reduce the time and risk required to develop the algorithm. This is done, in part, by reducing or eliminating syntax errors (eg, due to the complexity of a particular programming language), and by providing live evaluation and feedback of the algorithms being built (eg,). Achieved (by flagging errors and anticipating logical debugging) while the algorithm is being built.
The algorithm may be stored as defined in algorithm area 210. The algorithm may also be given a name (eg, during algorithm construction and / or when the algorithm is saved). Thus, the saved algorithm may later be called up or referenced by trading interface 200 or another trading interface. For example, the saved algorithm may be loaded by the trading interface 200 so that it can be edited or reused for another order. As another example, the saved algorithm may be referenced as one order type from another trading interface as described below.
FIG. 2J shows a trading interface 290 according to a predetermined embodiment. The trading interface 290 is an order ticket adapted to prepare for the initiation of an order managed by the algorithm, if the algorithm is specifically defined for that order.
The trading interface 290 includes an algorithm area 299, an algorithm order button 294, and a building block button 295. The algorithm area 299 includes a price area 291, a quantity area 292, and a conditional area 293. Price area 291 is similar to price area 211 discussed above. The quantity area 292 is similar to the quantity area 212 discussed above. Conditional area 293 is similar to conditional area 213 discussed above. The building block button 295 is similar to the building block button 215 discussed earlier.
The trading interface 290 may be used to initiate the execution of a typical trading order. In addition, the algorithm order button 294 may be selected to activate the algorithm area 299. When enabled, the algorithm order area 299 prepares to define the algorithm using the price area 291 and the quantity area 292 and the conditional area 293 as in the method discussed above for the trading interface 200. Once the algorithm is defined and initiated in algorithm area 299, it is managed according to the defined algorithm, similar to the method discussed above for trading interface 200.
Similarly, algorithm areas and building block buttons similar to those in trading interfaces 200 and 290 may be incorporated into other components of the trading application. For example, the hedge manager interface may be adapted to incorporate similar functionality so that the algorithm can be defined and specified to manage hedge orders.
The components, elements and / or functions of the trading interface 200 and trading interface 290 discussed above may be implemented alone or in combination in various forms, for example as an instruction set in hardware, firmware and / or software. Certain embodiments are provided as an instruction set that resides on a computer-readable medium such as memory, a hard disk, a CD-ROM, a DVD, an EPROM, and / or a file server for execution on a general purpose computer or other processing device. You may. III. Algorithm Design Lab
Certain embodiments provide design canvas areas and blocks for designing algorithms. Certain embodiments provide blocks with complex functions for use in algorithms. A predetermined embodiment provides for grouping a plurality of blocks placed within a design canvas area. A given embodiment prepares a virtualized group block that allows some dynamic instantiation of the algorithm to handle certain discontinuous events. Certain embodiments are expected to rapidly adjust both the parameters and logic of the algorithm, even during a single trading session. Certain embodiments provide live feedback of blocks as the algorithm is defined. Certain embodiments provide safety features to reduce potential errors when the algorithm is designed. A predetermined embodiment prepares the operation of some or all parts of the algorithm when the connection between the client device and the algorithm server is broken. In certain embodiments, the user writes programming code at the risk of a traditionally programmed algorithm, such as syntax errors, ambiguous logic, and the need for a non-trader programmer to develop the algorithm as specified by the trader. Reduce by reducing or eliminating. A given embodiment provides a single application for building algorithms, debugging and simulating (using real market data) all at the same time. In addition, this single application may also prepare for the initiation of an algorithmic order.
FIG. 3A is a block diagram showing an electronic trading system 300 in which a given embodiment can be used. System 300 includes one or more client devices 301, one or more algorithm servers 302, and one or more electronic exchanges 303. Each client device 301 is communicating with one or more algorithm servers 302. Each algorithm server 302 is communicating with one or more exchanges 303. Further, in certain embodiments, although not shown in FIG. 3A, the client device 301 may be communicating with one or more exchanges 303. Communication with the exchange by the client device 301 and / or the algorithm server 302 may be, for example, via a gateway similar to the gateway 120 discussed above.
The client device 301 may be, for example, similar to the client device 110 discussed above. In certain embodiments, the client device 301 may also be referred to as a trader terminal. Exchange 303 may be, for example, similar to Exchange 130 discussed above.
In certain embodiments, the algorithm server 302 is physically positioned near or at exchange 303. In certain embodiments, the algorithm server 302 is part of the client device 301.
In operation, the algorithm for electronic commerce may be designed on the client device 301. The algorithm may then be propagated to the algorithm server 302. The algorithm server 302 executes an algorithm to execute an electronic transaction with the exchange 303. Market data may be received by algorithm server 302 for use by the algorithm. In addition, market data may be received by client device 301 for use in algorithm design. Market data may be received, for example, from exchange 303. As another example, market data may be received from the simulator or from stored / historical data.
FIG. 3B shows a trading interface 310 according to a predetermined embodiment. The trading interface 310 is a trading interface for an algorithmic trading application called the Algorithm Design Lab ("ADL"). ADL allows traders to design algorithms for electronic trading. However, it should be understood that the elements of trading interface 310 shown may be incorporated into other trading interfaces.
The trading interface 310 includes a design canvas area 311, a block list area 312, a variable area 313, and a control area 314. In certain embodiments, one or more of these areas may be in separate windows or toolbars. For example, the block list area 312 may be in a window separate from the design canvas area 311.
In operation, the algorithm is defined in the design canvas area 311 by utilizing one or more blocks from the block list area 312. Default values for user-defined variables in the algorithm may be specified using variable area 313. Once the algorithm is defined, the algorithm may be simulated using the controls within control area 314 to show how the logic of the algorithm behaves. The trading interface may then be used to initiate orders that should be managed according to a defined algorithm.
Design canvas area 311 prepares to define the algorithm. The design canvas area 311 may also be referred to as the whiteboard area. The design canvas area 311 provides a visual programming environment for designing algorithms. Designing an algorithm involves building, testing, simulating and / or evaluating the algorithm.
In certain embodiments, the design canvas area 311 is the primary focus of the interface for the trading application 310, which may be, for example, a large white space. In the design canvas area 311 the blocks may be arranged according to the user's preference. In certain embodiments, the design canvas area 311 provides grid lines that may be used in the array of blocks. In certain embodiments, the design canvas area 311 includes a summary view or map that can be used to guide through a large algorithm with many blocks. In certain embodiments, the design canvas area 311 may be zoomed in or out so that the user can see the algorithm more or less at once.
Blocks are placed in the design canvas area 311 and connected to define the algorithm. The block to be placed may be selected from the block list area 312. Once placed, the block may be connected to other placed blocks.
The block list area 312 contains one or more blocks that can be selected and placed within the design canvas area 311. The blocks represent different features that can be combined to build the algorithm according to the user's preference.
In general, a block has an input and an output. However, certain blocks may have only inputs, and other blocks may have only outputs. For example, the pause block may have only inputs. As another example, the numeric block may have only output.
The input and output of the block are of two main types, either continuous or discontinuous. Continuous type inputs / outputs have values (hence constantly) at any particular time. Discontinuous type inputs / outputs receive / provide discontinuous events (individual messages / objects) in response to specific actions / events that occur at some special time. When a specific action / event occurs, the corresponding discontinuous event may occur.
In addition to this main type of input / output, the input / output may have a special value type. For example, continuous input may have value types such as Boolean, number, integer, floating point or instrument value. As another example, a block may have inputs of two consecutive variable value types, in which case the value types of the two inputs may be, for example, Booleans or numbers, but they must be of the same type. Must be. An equal sign block that takes two inputs and compares them to output a Boolean value that indicates whether they are equal can be used, for example, to compare a Boolean value or a number or instrument value with a variable input. You may have. As another example, the discontinuous output may have a fill confirmation value type. That is, the discontinuous output may provide a discontinuous event for execution confirmation. As another example, discontinuous output can be used for order request confirmation (indicating that an order has been placed), execution confirmation (indicating that an order has been filled or partially filled), and order change confirmation. (Indicates that the accepting order parameters such as price or quantity have changed), order deletion confirmation (indicates that the accepting order has been deleted or canceled) or transaction confirmation (transaction has occurred) It may also provide two or more types of discontinuous events for actions such as). As another example, a discontinuous event may simply be empty to indicate that an event is occurring. Empty discontinuous events may be triggered, for example by timers, Boolean changes, or to trigger part of the algorithm at a specific time (such as when a time or, for example, certain market conditions are met). It may be used for. One particular type of discontinuous event may contain different information than another type of discontinuous event. For example, the order confirmation may include information such as an order identifier and / or an instrument. As another example, the discontinuous event of execution confirmation is the order identifier, price, quantity, instrument and / or execution time. Etc. may be included. As another example, the order deletion confirmation may include an order identifier, an instrument and / or a deletion time. As another example, an empty discontinuous event may not contain any information (or may only contain the time of occurrence of the event). The discontinuous event may include user-defined information. For example, the discontinuous event of the execution confirmation of the executed order regarding Instrument A may include user-defined market information such as the bid price of Instrument B at the time of execution of Instrument A.
In certain embodiments, the block comprises an indicator of the main type of its input / output. For example, continuous inputs / outputs may be represented by special background colors, foreground colors, background patterns, border colors, border styles, shapes, symbols, numbers, text and / or fonts, and discontinuous inputs. / Output may be displayed in different colors, patterns, boundaries, shapes, symbols, numbers, text and / or fonts.
In certain embodiments, the block comprises an indicator of its input / output value type. For example, inputs / outputs with special value types may be displayed by special background color, foreground color, background pattern, border color, border style, shape, symbol, number, text and / or font, different values. Inputs / outputs with types may be represented by different colors, patterns, boundaries, shapes, symbols, numbers, text and / or fonts.
In certain embodiments, when the cursor is positioned near the block, the main type and / or value type input or output is displayed in a pop-up window. In certain embodiments, when the cursor is positioned near the block, information about the block's settings is displayed in a pop-up window.
Blocks represent different functions. In trading interface 310, blocks are divided into four general functional categories: basic blocks, trading blocks, discontinuous blocks and other blocks. However, these groupings are for convenience of organization and user use, the blocks do not need to be grouped, and the grouping of blocks does not require any special function. Some blocks may fit into more than one category as appropriate, and other formations or groupings of the block may be used.
The basic block generally has continuous inputs and outputs, and compares arithmetic operations (eg, addition, subtraction, multiplication and division), logical operations (eg, AND, OR and equal signs, greater than or less than, etc.). ), Constant values (eg, numeric and Boolean values) and if-then-else configurations are provided.
Trading blocks generally provide more complex functionality with respect to order operations (eg, ordering, modifying existing orders or deleting orders), or with respect to order-related information (eg, execution confirmation). The trading block may have both continuous and discontinuous inputs and outputs. For example, a market maker block may have a continuous input to specify instruments, prices, quantities and conditions for pricing orders, and a continuous output of the quantity being accepted and It may have a discontinuous output to provide execution notifications. Trading blocks allow users, including non-programmers (such as traders), to use a visual design environment (such as those provided by ADL) to generate and deploy trading algorithms. The trading block may anticipate an algorithm with a faster and more accurate design than a typical programmer with fewer steps, or an instruction with a faster and more accurate design than other visual programming platforms.
Discontinuous blocks generally have discontinuous inputs and outputs and provide operations based on the occurrence of discontinuous events. For example, the generator block may generate the occurrence of discontinuous events. As another example, the value extractor block may extract a value from a discontinuous event and use it as a continuous value to make available to another part of the algorithm. As another example, sequencer blocks may be used to control the sequence in which continuous blocks are processed in response to discontinuous events. A given discontinuous block may store data to be referenced at subsequent times. For example, the value multiplier block may receive a discontinuous event and extract a user-specified value from it. The extracted values may be cumulative with the values extracted from each discontinuous event received.
Other blocks provide various features that may not necessarily fall into the categories described above. For example, these blocks may provide dedicated or more complex calculations, or they may add additional control to the execution of the algorithm itself. In addition, other blocks provide more precise tools for controlling risk, converting numbers to tradeable values, or using time (whether accurate time or elapsed time) as an input or variable. You may.
FIG. 3C shows an example of block 320 that may be used in trading interface 310 according to a given embodiment. The figure shows block examples from each of the previously identified categories. An example of a basic block includes an addition block 321 and an if-then-else block 322. Examples of trading blocks include a market maker block 323, a conditional sell / buy block 324, and an order handler block 325. Examples of discontinuous blocks include a value extractor block 326 and a branch block 327. Other block examples include note block 328 and pause block 329. Each of these blocks, as well as other examples of blocks that may be included in a given embodiment, will be discussed in more detail below.
Basic blocks may include, for example, addition, subtraction, multiplication, division, greater than or less than, greater than or equal to, less than or equal to, AND, OR, equal sign, IF-THEN-ELSE, numbers, Booleans and constant blocks.
The addition block may combine two continuous numeric inputs to produce one continuous numeric output. The addition block may have a triangular shape with a plus sign ("+") in the middle, two continuous inputs on the left and one continuous output on the right. The adder block is sometimes referred to as an adder block.
The subtraction block may generate one continuous numeric output by subtracting one continuous numeric input (eg, bottom input) from a second continuous numeric input (eg, top input) . The subtraction block may have a triangular shape with a minus sign ("-") in the middle, two continuous inputs on the left and one continuous output on the right.
The multiplication block may multiply two continuous numeric inputs to produce one continuous numeric output. The multiplication block may have a triangular shape with a multiplication symbol ("X" or "*") in the middle, two continuous inputs on the left and one continuous output on the right.
The division block may generate one continuous numeric output by dividing one continuous numeric input (eg, top input) by a second consecutive input (eg, bottom input). The division block may have a triangular shape with a division sign ("/" or "÷") in the middle, two continuous inputs on the left and one continuous output on the right.
The greater than block may compare two continuous numeric inputs to determine if one input (eg, top input) is greater than the second input (eg, bottom input). The output is a continuous Boolean output "true" if the first input is greater than the second input, and "false" in all other situations. The greater block has a rectangular shape on the left and an arched shape on the right, with a greater-than sign (">") in the middle, two continuous numeric inputs on the left and one continuous Boolean output on the right. May be good.
The lesser block may compare two continuous numeric inputs to determine if one input (eg, top input) is less than the second input (eg, bottom input). The output is a continuous Boolean output "true" if the first input is less than the second input, and "false" in all other situations. The small block has a small sign ("<") in the middle, two continuous numeric inputs on the left and one continuous Boolean output on the right, with a rectangular shape on the left and an arched shape on the right. May be good.
The block may compare two continuous numeric inputs to determine if one input (eg, top input) is greater than or equal to the second input (eg, bottom input). The output is a continuous Boolean output "true" if the first input is greater than or equal to the second input, and "false" in all other situations. The above block has a rectangular or arched shape on the left, with a symbol ("> =" or ">-") in the middle, two continuous numeric inputs on the left and one continuous Boolean output on the right. May have.
The following block may compare two continuous numeric inputs to determine if one input (eg, top input) is less than or equal to the second input (eg, bottom input). The output is a continuous Boolean output "true" if the first input is less than or equal to the second input, and "false" in all other situations. The following block has the following symbol ("<=" or "<-") in the middle, two continuous numeric inputs on the left and one continuous Boolean output on the right, rectangular on the left and arched on the right. May have.
The AND block is 2 so that the Boolean output is "true" if the first input (eg top input) is "true" and the second input (eg bottom input) is "true". You may perform a logical product of two continuous Boolean inputs. If any of the inputs are "false", the output value is "false". The AND block may have a rectangular shape on the left and an arched shape on the right, with the text "AND" in the middle, two continuous Boolean inputs on the left and one continuous Boolean output on the right.
The OR block may be ORed by two continuous Boolean inputs so that the Boolean output is "true" if any of the inputs are "true". If both inputs are "false", the output value is "false". The OR block may have a rectangular shape on the left and an arched shape on the right, with text (OR) in the middle, two continuous Boolean inputs on the left and one continuous Boolean output on the right.
The equal sign block may compare two consecutive inputs to determine if one input (eg, top input) is equal to the second input (eg, bottom input). The inputs may be of variable value type, as long as each input is of the same type, the equation block may accept values such as numbers, Booleans or instruments. The output is a continuous Boolean output "true" if the two inputs are equal, and all "false" in all other situations. The equal sign block has an equal sign ("=") in the middle, two consecutive variable inputs on the left and one continuous Boolean output on the right, even if it has a rectangular shape on the left and an arched shape on the right. Good. The equal sign block is sometimes referred to as the equality block.
The IF-THEN-ELSE block may have three continuous inputs: a Boolean IF input, a variable THEN input and a variable ELSE input. The IF-THEN-ELSE block has one continuous variable output. If the IF input value is "true", then the output is the value of the THEN input. If the IF input value is "false", then the output is the value of the ELSE input. The IF-THEN-ELSE block has a rectangular shape with a "?" Symbol in the middle, one continuous Boolean IF input on the left and two continuous variable ELSE inputs and THEN input and one continuous variable output on the right. You may.
The numeric block may have one continuous numeric output that provides a numeric value specified by the user. Once placed, the user may be prompted to enter a number in the number block. Alternatively, the number block may default to a default value such as 1. In addition, the value may be specified in the order ticket quantity or order ticket price. If so, the value of the numeric block will be the individual value specified when the order is started to be managed using the algorithm. The specified value may be modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a numeric block and enter the value. Good. Further, the specified value may be changed by using the variable area 313 described later as long as the number block is specified to be variable. The digit block may have a circular shape with a number specified in the middle and one continuous numeric output on the right side. This block is sometimes referred to as a constant block.
A Boolean block may have one continuous Boolean output that provides a Boolean value specified by the user. Once placed, the user may be prompted to enter a Boolean value in the Boolean block. Alternatively, the Boolean block may default to a default value such as "true". The specified value may be modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a Boolean block and enter the value. Good. Further, the specified value may be changed by using the variable area 313 described later as long as the Boolean block is specified to be variable. The Boolean block may have a circular shape with the Boolean value specified in the middle displayed in text and one continuous Boolean output on the right. This block is sometimes referred to as the constant Boolean block.
In certain embodiments, numeric blocks and Boolean blocks may be merged into a single block, such as a constant block. The constant block may have one continuity variable output that provides a number specified by the user. Once deployed, the user may be prompted to enter a value type and value in the fixed value block. Alternatively, the constant block may default to a default value type such as a number and a default value such as 1. In addition, the value may be specified in the order ticket quantity or order ticket price. If so, the value of the constant block will be the individual value specified when the order is started to be managed using the algorithm. The specified value may be modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a constant block and enter the value. Good. Further, the specified value may be changed by using the variable area 313 described later as long as the constant block is specified to be variable. The constant block may have a circular shape with the value specified in the middle displayed in text and with one continuous variable output on the right. In certain embodiments, the constant block may also support the designation of an instrument as a value, similar to the instrument block described below.
Trading blocks are, for example, instruments, instrument attributes, market makers, leggers, custom spreads, responsive sell / buy, conditional sell / buy, order handlers, IF-THEN-ELSE instruments, price instruments. It may include blocks of ment attributes, price ranges, transactions, orders, contract calculators and contract accumulators.
The instrument block may have one continuous instrument output that provides the instrument name. The instrument name may be, for example, an exchange-listed instrument or a synthetic instrument. Once deployed, the user may be prompted to specify the instrument name in the instrument block. The instrument name may be selected from the list, for example. Alternatively, the instrument block may default to the default value. The specified value is modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select an instrument block and enter a value. You may. Further, the specified value may be changed by using the variable area 313 as long as the instrument block is specified to be variable.
The instrument attribute block may have a continuous instrument input and a continuous numerical output. The instrument attribute block may adopt the instrument name and output a value to the specified attribute of the instrument. The attributes are Best Buy Quantity, Best Buy Price, Best Sell Quantity, Best Sell Price, Volume, Session High, Session Low, Minimum Increment that can be traded, Final Trading Price, Final Trading Quantity, Total Quantity (New) Total quantity traded at the final trading price until the trading occurs at the price), settlement value from the upfront trading session, actual (non-implicit) best buy quantity, actual (non-implicit) best sell quantity, buy It may include headcount (number of orders in the market at the best bid price), sell headcount (number of orders in the market at the best sell price) or position (total inventor of the user in a special instrument). .. Once deployed, the user may be prompted to enter the attributes that should be provided by the instrument attribute block. Alternatively, the instrument attribute block may default to a default value such as the buy quantity. The specified attributes are modified by the user while designing the algorithm, for example by using an action such as a menu item or double-click that should be prompted to select an instrument attribute block and enter the attribute. May be done. Further, the specified attribute may be changed by using the variable area 313 described later as long as the instrument attribute block is specified to be variable.
The market maker block places a sell or buy order for a tradable object specified by a continuous instrument input with a price specified by two continuous numeric inputs if the conditional continuous Boolean input is "true". And may be submitted in quantity. Conditional input is optional and defaults to "true" if no input is given. The market maker block may delete the order if the condition input is "false". The market maker block may modify the price or quantity of an existing order if the individual price and quantity entries change. The value specified in the quantity entry represents the desired maximum contract quantity, taking into account the preceding contract. For example, given a quantity entry value of 5, order 5 may be entered into the market, and if quantity 3 is executed, order 2 will continue to function even if the price entry changes. If the quantity entry changes, the functioning order will be the specified new quantity minus the already filled quantity 3. The market maker block may provide one or more discontinuous outputs that provide discontinuous events for execution confirmation and / or order requests. The market maker block also includes an option to specify that orders generated by the market maker block should remain in the order book even if the algorithm is deleted, suspended, suspended, or suspended. Good. This feature may be useful, for example, in the hedging portion of the algorithm. The market maker block may include an option to specify that the order generated by the market maker block is marked as a hang while it appears in the purchase order (eg, the order is an order). It may work improperly (even if it is not expected to stay in the book) or make it easier to identify incomplete algorithms. The market maker block is also associated with the order placed by the market maker block, for example to make it easier to identify them in the order window.
The legger block may submit buy or sell orders for the tradable objects of the legs of the custom spread, in which case the tradable objects of each leg are specified by the continuous instrument input. The desired price and quantity for a custom spread is specified by two continuous numeric inputs. The legger block raises individual orders for spreads when the conditional continuity Boolean input is "true". Conditional input is optional and defaults to "true" if no input is given. The legger block may delete the order if the condition input is "false". The legger block may also modify the price and / or quantity of the order being accepted if the price and / or quantity input value changes. The value specified in the quantity entry represents the desired maximum contract amount of the spread taking into account the preceding contract. For example, given a quantity entry value of 5, order 5 may be entered into the market, and if quantity 3 is executed, order 2 will continue to function even if the price entry changes. If the quantity entry changes, the functioning order will be the specified new quantity minus the already filled quantity 3. The legger block may provide one or more discontinuous outputs that provide discontinuous events for spread executions, order requests and / or leg executions. After the instrument is provided for the spread leg, the leger is set, for example, by selecting a leger block and using an action such as a menu item or double click that should be prompted to specify parameters and settings. May be done. The parameters that can be specified for each leg of the spread are "multiple" (coefficient of the spread leg), "transaction quantity" (quantity of each leg of the spread, where positive numbers are buys and negative numbers are sells). "Make the market work?" (Toggle whether the spread leg actively bids), "Net volatility" (Toggle whether to convert custom spread calculations to net volatility instead of price), "Pay" "Up tick" (custom spread is the minimum price increment when entering a limit order on a lean leg, positive means more aggressive towards closing, negative is less aggressive towards closing (Meaning not) and "lean ratio" (a unit of measure required to be on a lean leg to work one unit of measure on the quoted leg, which is, for example, the quantity ratio between two legs. It may also be the threshold quantity in a lean leg). Possible settings are "side" (buyer or seller of custom spread), "always work the on-site market" (if true, the legger block simply works the best or individual leg orders that appear on the on-site market. And, in certain embodiments, simply toggle the leg to work as determined by looking at the market sell / buy size ratio), "disable the" sniping "mode." (Legger Block will delete the current order being accepted if the desired spread price can be achieved, and at the same time toggle the default behavior of placing an order to close at the desired spread price for all legs. Invalidate. When done, the legger block will only work the specified "work market?" Leg even if the desired price is momentarily available), "clip size" (by entering the spread quantity with the total quantity specified). Specifies a user-defined flag associated with a discontinuous event in a spread execution to make it easier to identify the "quantity to function at one time" and "flag" (quantity to function at one time, which grows repeatedly until it is filled as defined) ) Is included. The legger block may include an option to specify that the order generated by the leger block should remain in the order book even if the algorithm is deleted, suspended, suspended, or paused. The leger block is an option to specify that the orders generated by the leger block will be marked as hung while they appear in the order book. May include, which may make it easier to identify improperly functioning or incomplete algorithms (for example, even if the order is not expected to stay in the order book). .. The legger block may also include an option to specify the color or text flag associated with the order placed by the legger block, for example to make it easier to identify them in the order window. This block is sometimes referred to as an autospread block or spreader block.
A custom spread block may submit a buy or sell order for a tradable object on the leg of the custom spread, in which case the custom spread will be provided as an instrument from an external application. The desired price and quantity for a custom spread is specified by two continuous numeric inputs. A custom spread block raises an individual order for a spread if the conditional continuity Boolean input is "true". Conditional input is optional and defaults to "true" if no input is given. Custom spread blocks may delete orders if the condition input is "false". Custom spread blocks may also modify the price and / or quantity of an open order if the price and / or quantity input value changes. The value specified in the quantity entry represents the desired maximum contract amount of the spread taking into account the preceding contract. For example, if a quantity entry value of 5 is given and a quantity of 3 is executed, order 2 will continue to function even if the price entry changes. If the quantity entry changes, the functioning order will be the specified new quantity minus the already filled quantity 3. Instead of requiring the hedge leg to present the original order quantity, the custom spread block may optionally include a Boolean input to enable dynamic sizing of the order quantity for the individual order leg. The custom spread block may provide one or more discontinuous outputs that provide discontinuous events for execution confirmation and / or order requests. Once deployed, the user may be prompted by an external application to specify a custom designed instrument, in which case the custom designed instrument provides synthetic market data representing the trading strategy. Alternatively, the specified custom-designed instrument can be customized by the user, for example, by selecting a custom spread block and from an external application while designing the algorithm. It may be specified and / or modified by using an action such as a menu item or double click that should be prompted to specify the design instrument. In addition, while designing the algorithm, the user "disables the" sniping "mode" (custom spread blocks delete the current order being accepted if the desired spread price can be achieved, at the same time. Toggle the default behavior of placing an order to close at the desired spread price for all legs. When disabled, the custom spread block will be at the specified quote even if the desired price is momentarily available. Settings that may include (only the legs work), and "clip size" (a quantity that should work at one time, repeatedly increasing until the total quantity is met as defined by the specified spread quantity input). You may specify it. The custom spread block also includes an option to specify that the orders generated by the custom spread block should remain in the order book even if the algorithm is deleted, suspended, suspended, or paused. Good. The custom spread block may include an option to specify that the order generated by the custom spread block is marked as a hang while it appears in the purchase order, which (for example, the order is an order). It may work improperly (even if it is not expected to stay in the book) or make it easier to identify incomplete algorithms. Custom spread blocks may also include an option to specify the color or text flags associated with the order placed by the custom spread block, for example to make it easier to identify them in the order window. .. In certain embodiments, the custom spread block may provide a specified custom designed instrument from an external application as a continuous instrument output. Place In certain embodiments, the custom spread block may provide a specified number or Boolean value from an external application as a continuous number or Boolean output. This block is sometimes referred to as a custom strategy block or a custom external application block.
The responsive sell / buy block may start submitting a buy or sell order for the instrument specified by the continuous instrument input when a discontinuous event is received on the discontinuous input. The order price and / or quantity may be provided by continuous numerical input. Alternatively, the price and / or quantity may be specified by a user-defined equation that is evaluated to determine the individual price or quantity value to be used. In certain embodiments, one of the price and quantity may be provided by continuous numerical input and the other may be provided by evaluating a user-defined equation. The specified price and / or quantity equation (if used) should be prompted by the user, for example, to select a responsive sell / buy block and enter the equation while designing the algorithm. Alternatively, it may be changed by using an action such as double-clicking. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. Once the Responsive Sell / Buy block initiates an order, the order will not be updated based on subsequent changes in the price and / or quantity value offered. Responsive sell / buy blocks provide an option to specify that orders generated by responsive sell / buy blocks should remain in the order book even if the algorithm is removed, suspended, suspended, or paused. It may be included. Responsive sell / buy blocks may include an option to specify that the orders generated by the responsive sell / buy blocks are marked as hung while they appear in the order book, which (eg, orders). May work improperly (even if it is not expected to stay in the purchase order) or make it easier to identify incomplete algorithms. Responsive sell / buy blocks also make it easier to identify them, for example in the order window.
A conditional sell / buy block places a sell or buy order for an instrument specified by a continuous instrument input by two continuous numeric inputs if the conditional continuous Boolean input is "true". It may start at the specified price and quantity. Conditional input is optional and defaults to "true" if no input is given. The conditional sell / buy block does not delete the order even if the condition input value is "false" (however, the order does not start until the condition input becomes "true"). Conditional sell / buy blocks may only submit one order at a time. In certain embodiments, the conditional sell / buy block is an order to achieve the original quantity value provided, even if the order is deleted (eg, by another block in the algorithm or manually by the user). Continue to submit (one order at a time). Once the conditional sell / buy block initiates an order, the order is not updated based on subsequent changes in the price and / or quantity value offered. The conditional sell / buy block may provide one or more discontinuous outputs that provide discontinuous events for execution confirmation and / or order requests. The conditional sell / buy block is for specifying that the order generated by the conditional sell / buy block should remain in the order book even if the algorithm is deleted, suspended, suspended, or suspended. Options may be included. The conditional sell / buy block may include an option to specify that the order generated by the conditional sell / buy block is marked as a hang while it appears in the order book, which (eg, for example). It may work improperly (even if the order is not expected to stay in the order book) or may make it easier to identify incomplete algorithms. Conditional sell / buy blocks also have an option to specify the color or text flag associated with the order placed by the conditional sell / buy block, for example to make it easier to identify them in the order window. May include.
The order handler block may receive an order event on a discontinuous input and manage the corresponding order on the basis of the price and quantity values provided by the two continuous numeric inputs. If the value provided in the continuous Boolean input is "true", the order is deleted. The order handler block may provide one or more discontinuous outputs that provide discontinuous events for execution confirmation, deletion confirmation and / or change confirmation. The order handler block may provide the quantity being accepted and / or the quantity executed to the continuous numeric output. The order handler block may include an option to specify that orders managed by the order handler block should remain in the order book even if the algorithm is deleted, suspended, suspended, or paused.
The IF-THEN-ELSE instrument block may have three continuous inputs: a Boolean IF input, an instrument THEN input and an instrument ELSE input. The IF-THEN-ELSE instrument block has one continuous instrument output. If the IF input value is "true", then the output is the instrument value of the THEN input. If the IF input value is "false", then the output is the ELSE input instrument value. The IF-THEN-ELSE instrument block has a "?" Symbol in the middle, one continuous Boolean IF input on the left and two continuous instruments ELSE input and THEN input and one continuous instrument on the right. It may have a rectangular shape with an output. The IF-THEN-ELSE instrument block is similar to the IF-THEN-ELSE block discussed earlier, but is specialized for instrument values.
The pricing instrument attribute block may have a continuous instrument input, a continuous numerical input, and a continuous numerical output. The Price Instrument attribute block adopts the instrument name (provided by continuous instrument input) and price (provided by continuous numeric input) and specifies the instrument at the specified price. You may output the value to the attribute to be done. The attributes are buy quantity, sell quantity, actual (non-implicit) buy quantity, actual (non-implicit) sell quantity, buy head count (number of buy orders in the market at the specified price) and sell head count (at the specified price). The number of sell orders in the market) may be included. Once deployed, the user may be prompted to enter the attributes that should be provided by the Price Instrument Attribute Block. Alternatively, the price instrument attribute block may default to a default value such as the buy quantity. The specified attribute uses an action such as a menu item or double-click that the user should be prompted to select and enter the attribute at the time of price instrument attribute block while designing the algorithm. May be changed by Further, the specified attribute may be changed by using the variable area 313 described later as long as the instrument attribute block at the time of price is specified to be variable.
The price range block may have two continuous instrument inputs and one continuous instrument output. Price range blocks employ two instrument names (for example, one from the "front leg" input and the other from the "back leg" input) and are listed by the exchanges of the two instruments offered. The instrument name corresponding to the spread (eg, "front leg-back leg") may be output. For example, the price range block may be used to refer to spreads between two different instruments such as "CLZ0" (December 2010 crude oil) and "CLF1" (January 2011 crude oil). These "legs" may be referred to as "front legs" and "back legs," respectively. The corresponding output of the price range block is the exchange-listed spread instrument, in this example the exchange-listed instrument "CLZ0-CLF1" (December 2010-January 2011 spread market). Is. This block may be used to increase programming security to reduce errors in the process of correctly referencing spreads between instruments. For example, the two instruments entered are specified to be variables that can be changed during the execution of the algorithm, or different spreads that the exchange lists for different orders managed by the algorithm. It may be displayed as a variable that can be used. The price range block provides security by finding the listed "correct" spread instruments without having to set or change the third variable to match the two individual instrument variables. Price range blocks may also be used to locate or search for the presence of a given spread listed by an exchange.
The trading block may provide the discontinuous event output with transaction data in the discontinuous event for the instrument provided in the continuous instrument input. Discontinuous events include transaction price values and transaction quantity values associated with each transaction. Transaction data may be received, for example, from an exchange. The transaction price and the transaction quantity may be extracted from the discontinuous event, for example, by a value extractor block, a value multiplier block, a discontinuous minimum block and / or a discontinuous maximum block.
Order blocks may allow existing orders (ie, orders that have already been placed outside an algorithm but are not managed by another algorithm) to be managed according to a defined algorithm. For example, order blocks may be used to provide certain types of auto-hedging routines that limit orders that have been manually placed by the user. The order block provides a continuous instrument output of the instruments associated with the existing order, and a continuous numerical output of the quantity, price and executed quantity of the existing order. The order block also provides discontinuous output for order discontinuous events such as execution confirmation related to the order. In certain embodiments, if the defined algorithm contains an order block, this algorithm is presented in a list of available algorithms to be applied to an existing order, eg, in a trading interface including an order window. May be good. As another example, the order identifier may be provided as a variable to the algorithm if the algorithm is executed or specified in the order block itself. When applied to an existing order, a defined algorithm containing an order block may manage the order according to that algorithm.
The contract computer block may provide discontinuous output for discontinuous events of spread contracts. The contract calculator block may be used when the algorithm buys / sells a custom spread without using a legger block or a custom spread block. The execution calculator block receives multiple continuous instrument inputs and one discontinuous input for each transaction execution (execution) leg of the spread, the former providing the instrument of the leg and the latter confirming the execution. Providing discontinuous events. After the instrument is provided for the spread leg, the trader block uses an action such as a menu item or double click that should be prompted to select the trader block and specify parameters and settings, for example. It may be set by. The parameters that can be specified for each leg of the spread are "multiple" (coefficient of the spread leg), "transaction volume" (quantity of each leg of the spread, where positive numbers are buys and negative numbers are sells). Includes "net fluctuations" (toggle whether custom spread calculations are converted to net fluctuations instead of prices). Possible settings include "side" (buyer or seller of custom spreads on the execution calculator) and "flags" (user-defined flags associated with discontinuous events in spread executions for easier identification. Specified) is included.
The multiplier block may receive discontinuous events of orders or executions at the discontinuous input and may provide the integrated quantity of the received discontinuous events to the continuous numerical output. For example, if the integrator block is connected to the market maker block, the integrator block may increase the value of its continuous numerical output for each partial execution discontinuous event received from the market maker block. Good. This block may be used, for example, to track the total number of contracts. The multiplier block may be a pass-through block, so that each discontinuous event received is emitted via a corresponding discontinuous output. The multiplier block may include a reset discontinuous input that resets the integrated quantity to 0 upon receiving an event. The integrator block may be similar to the value integrator block described later, but has a more limited function because it integrates only the contracted quantity.
Discontinuous blocks include, for example, generators, value extractors, value aggregators, value buckets, discontinuous moving averages, states, branches, multiplexers, funnels, sequencers, discontinuous minimum blocks and discontinuous maximum blocks. May be included.
The generator block may provide a discontinuous event for the discontinuous output whenever the condition is "true". The condition may be provided by a continuous Boolean input so that the event is fired each time the condition input is "true". Alternatively, the condition is "at the start" (the condition is "true" at the start of the algorithm and then "false", thus providing a single discontinuous event at the start of the algorithm), " On change "(the condition is always" true "when the continuous Boolean input value changes, so both the transition from" true "to" false "or from" false "to" true "are discontinuous events. To be an event such as "every X" (the condition becomes "true" once every specified time interval, and the interval may be specified in minutes, seconds, or milliseconds). It may be specified.
The value extractor block may receive a discontinuous event with a discontinuous input and extract a user-specified value from the event. Alternatively, the value extractor block may evaluate a user-defined equation to determine the value to be extracted when a discontinuous event is received. The extracted values may then be provided to the continuous output. The value type of the output depends on the type of the extracted value. When specifying the values to be extracted from the discontinuous event, the following formulas: "Instrument" (providing the instrument associated with the discontinuous event), "Contract price" (associating with the discontinuous event) (Provides the contract price to be), "Contract quantity" (provides the contract quantity associated with the discontinuous event), "Order quantity" (provides the order quantity associated with the discontinuous event), "Order price" (provides the discontinuous event) "Provides the order price associated with consecutive events)," Execution quantity "(provides the accumulation of executions related to the order quantity)," Accepting quantity "(accumulation of the non-execution order quantity at a specific order price) (Provides), "Transaction Quantity" (provides the quantity of transactions performed on an exchange), "Transaction Price" (provides the price of transactions performed on an exchange) and "Variables" (specifies) The value of the user-defined variable given, or the value of any other block output in the algorithm that is not part of the virtualized group block) is available. In certain embodiments, the value extractor block may refer to a value from the output of another block. The value may be referenced, for example, using the expression "variable" discussed above, or the value may be provided to the continuous variable input of the value extractor block. The value extractor block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output.
The value multiplier block may receive the discontinuous event by the discontinuous input, extract the user-specified value from the event with the reception of each discontinuous event, and integrate the values. The integrated value is provided to the continuous numerical output. When specifying the values to be extracted from the discontinuous event, the following formulas: "Contract price" (provides the contract price associated with the discontinuous event), "Contract amount" (contract associated with the discontinuous event). "Provide quantity", "Order quantity" (provide order quantity associated with discontinuous event), "Order price" (provide order price associated with discontinuous event), "Execute quantity" (provide order quantity) "Available quantity" (provides an accumulation of non-executable order quantities at a particular order price), "Transaction quantity" (provides an accumulation of non-executable order quantities at a particular order price), "transaction quantity" (quantity of transactions executed on an exchange) (Provides), "Transaction Price" (provides the price of transactions performed on an exchange) and "Variables" (values of specified user-defined variables, or one of the virtualized group blocks in the algorithm. (Provides values for any other block output that is not a part) is available. The value multiplier block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output. The value multiplier block may include a reset discontinuous input that resets the integrated price to 0 upon receiving an event. The value integrator block is similar to the integrator block discussed above, but supports a more flexible setting as to what price is to be integrated.
The value bucket block prepares to generate a table of key-value pairs. This table may be, for example, a hash table. The key to the table in the value bucket block is called the bucket hole. The value of a table that corresponds to a particular bucket hole (ie, the table key) is called the bucket value. The value bucket block receives a discontinuous event on a discontinuous input. When a discontinuous event is received, a user-defined equation for bucketholes is evaluated to determine the appropriate entry in the table. The user-defined equation for the bucket value is then evaluated to determine the new bucket value for the entry corresponding to the determined bucket hole in the table. As will be described later, this new bucket value may be combined with or superseded by the preceding bucket value. Once deployed, the user may be prompted to enter a buckethole expression and bucket value. Alternatively, the value bucket block may default to default equations such as bucket hole "0" and bucket value "0". The specified equation should be prompted by the user while designing the algorithm, for example, to select a value bucket block and to enter one or both of the buckethole equation and the bucket value equation, such as a menu item or double click. May be modified by using the action of. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. The equations that can be used to specify the equation (which can be provided by the building block button) are "Instrument" (which provides the instrument associated with the discontinuous event), "Contract Price". (Provides a contract price associated with a discontinuous event), "Contract quantity" (provides a contract quantity associated with a discontinuous event), "Order quantity" (provides a discontinuous event) (Provides the order quantity associated with the order quantity), "Order price" (provides the order price associated with the discontinuous event), "Execution quantity" (provides the accumulation of executions related to the order quantity), "Reception "Quantity in" (provides an accumulation of non-executable order quantities at a particular order price), "Transaction Quantity" (provides the quantity of transactions performed on an exchange), "Transaction Price" (provides an exchange Provides the price of the transaction executed in (provides the price of the transaction) and "variable" (the value of the specified user-defined variable, or the value of any other block output in the algorithm that is not part of the virtualized group block. ) May be included. As part of specifying the value bucket equation, the user may also set how the new bucket value is combined with the preceding bucket value. For example, a new bucket value may be added to the preceding bucket value (providing the addition of the bucket value determined for the same bucket hole for each discontinuous event received). As another example, the average of the bucket values determined for the same bucket hole may be determined. As another example, a new bucket value may replace the preceding bucket value (providing the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. Provides a fixed accumulation), "Receiving Quantity" (provides an accumulation of non-executable order quantities at a particular order price), "Transaction Quantity" (provides the quantity of transactions executed on an exchange) ), "Transaction Price" (provides the price of a transaction performed on an exchange) and "Variable" (value of a specified user-defined variable, or part of a virtualized group block in an algorithm. (Providing values for any other block output) may be included. As part of specifying the value bucket equation, the user may also set how the new bucket value is combined with the preceding bucket value. For example, a new bucket value may be added to the preceding bucket value (providing the addition of the bucket value determined for the same bucket hole for each discontinuous event received). As another example, the average of the bucket values determined for the same bucket hole may be determined. As another example, a new bucket value may replace the preceding bucket value (providing the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. Provides a fixed accumulation), "Receiving Quantity" (provides an accumulation of non-executable order quantities at a particular order price), "Transaction Quantity" (provides the quantity of transactions executed on an exchange) ), "Transaction Price" (provides the price of a transaction performed on an exchange) and "Variable" (value of a specified user-defined variable, or part of a virtualized group block in an algorithm. (Providing values for any other block output) may be included. As part of specifying the value bucket equation, the user may also set how the new bucket value is combined with the preceding bucket value. For example, a new bucket value may be added to the preceding bucket value (providing the addition of the bucket value determined for the same bucket hole for each discontinuous event received). As another example, the average of the bucket values determined for the same bucket hole may be determined. As another example, a new bucket value may replace the preceding bucket value (providing the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. It may include (providing values for any other block output that is not part of the virtualized group block). As part of specifying the value bucket equation, the user may also set how the new bucket value is combined with the preceding bucket value. For example, a new bucket value may be added to the preceding bucket value (providing the addition of the bucket value determined for the same bucket hole for each discontinuous event received). As another example, the average of the bucket values determined for the same bucket hole may be determined. As another example, a new bucket value may replace the preceding bucket value (providing the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. It may include (providing values for any other block output that is not part of the virtualized group block). As part of specifying the value bucket equation, the user may also set how the new bucket value is combined with the preceding bucket value. For example, a new bucket value may be added to the preceding bucket value (providing the addition of the bucket value determined for the same bucket hole for each discontinuous event received). As another example, the average of the bucket values determined for the same bucket hole may be determined. As another example, a new bucket value may replace the preceding bucket value (providing the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. May (provide the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event. May (provide the latest value as the bucket value for a particular bucket hole). The value bucket may default to, for example, summing the bucket values for a particular bucket hole. The value bucket block may be a pass-through block, so each discontinuous event received is issued via the corresponding discontinuous output. The value bucket block may also have a hole continuous numeric input that provides a value that should be used as a bucket hole so that the corresponding bucket value of the provided bucket hole is provided in the value continuous numeric output. is there. The value bucket block may contain a reset discontinuous input that resets the stored table upon receiving an event.
The discontinuous moving average block may provide a moving average of values determined by evaluating a specified user-defined equation each time a discontinuous event is received on a discontinuous input. The number of data points to be used in determining the moving average is specified by continuous numeric input. The moving average is provided for continuous numerical output. The discontinuous moving average block may keep a list of evaluated data points until the number of data points specified by the corresponding input is achieved, at which point the latest data points are added to the list. It may be added, the oldest data point is removed from the list, and a moving average may be calculated across the data points in the list. Once placed, the user may be prompted to enter an equation to be evaluated. Alternatively, the discontinuous moving average block may default to a default value such as 0 for the equation. The specified equation is modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a discontinuous moving average block and enter the equation. May be done. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. The equations that can be used to specify the equation (which can be provided by the building block button) are "Instrument" (which provides the instrument associated with the discontinuous event), "Contract Price". (Provides the contract price associated with the discontinuous event), "Contract quantity" (provides the contract quantity associated with the discontinuous event), "Order quantity" (provides the order quantity associated with the discontinuous event) , "Order Price" (provides the order price associated with the discontinuous event), "Executed Quantity" (provides the accumulation of executions related to the order quantity), "Receiving Quantity" (at a specific order price) Of order quantity not executed "Providing accumulation"), "Transaction volume" (providing the quantity of transactions performed on an exchange), "Transaction price" (providing the price of transactions performed on an exchange) and "Variables" May include (providing the value of a specified user-defined variable, or the value of any other block output in the algorithm that is not part of the virtualized group block). Further, the discontinuous moving average block may adopt a discontinuous input which is a reset input. When a discontinuous event is received by the reset input, the recorded data points are abandoned. This can result in a moving average output of 0 or "non-number" (NaN). The discontinuous moving average block may also provide an OK continuous Boolean output that indicates whether enough data points have been recorded to fully calculate the moving average. The OK output is "false" until the required number of data points have been recorded, and "true" after that (until reset). For example, if the number of data points input provides a value of 20, then 20 data points (ie, each triggered by the reception of a discontinuous event) before the OK output is "true" of the specified equation. 20 ratings) need to be recorded. The discontinuous moving average block may also provide a continuous numerical output of the number of data points displaying the number of recorded data points. The discontinuous moving average block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output. When the event is received, the recorded data points are abandoned. This can result in a moving average output of 0 or "non-number" (NaN). The discontinuous moving average block may also provide an OK continuous Boolean output that indicates whether enough data points have been recorded to fully calculate the moving average. The OK output is "false" until the required number of data points have been recorded, and "true" after that (until reset). For example, if the number of data points input provides a value of 20, then 20 data points (ie, each triggered by the reception of a discontinuous event) before the OK output is "true" of the specified equation. 20 ratings) need to be recorded. The discontinuous moving average block may also provide a continuous numerical output of the number of data points displaying the number of recorded data points. The discontinuous moving average block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output. When the event is received, the recorded data points are abandoned. This can result in a moving average output of 0 or "non-number" (NaN). The discontinuous moving average block may also provide an OK continuous Boolean output that indicates whether enough data points have been recorded to fully calculate the moving average. The OK output is "false" until the required number of data points have been recorded, and "true" after that (until reset). For example, if the number of data points input provides a value of 20, then 20 data points (ie, each triggered by the reception of a discontinuous event) before the OK output is "true" for the specified equation. 20 ratings) need to be recorded. The discontinuous moving average block may also provide a continuous numerical output of the number of data points displaying the number of recorded data points. The discontinuous moving average block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output.
The state block may receive a discontinuous event at the discontinuous input and evaluate the conditional statement for each discontinuous output to determine if the discontinuous event should be provided to the discontinuous output. State blocks may be used to design state machines that are behavioral models, such as a finite number of states, transitions between these states, and actions. The state blocks may be linked together, similar to a "flow" graph that allows the user to examine how logic is executed when certain conditions are met. Since the current state is determined by the past state, it may essentially record information about the past. The transition is described by a conditional statement that displays the state change and must be met in order for the transition to take effect. State blocks allow users to define conditional statements that define exit actions and transitions. For example, in a state block, each providing two discontinuous outputs corresponding to different state transitions, the user specifies a conditional statement for each of them. After the discontinuous event is received, the state block waits for one or more of the conditional statements associated with each transition to be "true" (when the discontinuous event is received, the conditional statement). If none of them are "true"). When a conditional statement associated with a particular state transition evaluates to "true," the state block provides a discontinuous event (held since reception) to the output associated with that particular state transition. Conditional statements may be provided for continuous Boolean inputs. Alternatively, the conditional statement may be provided by a specified user-defined equation that evaluates a Boolean value. The specified equation may be modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a state block and enter the equation. Good. The equation may be textual or, for example, using a building block button similar to the building block button 215 discussed above. May be entered. State blocks may be used to evaluate user-defined patterns in the market, such as whether there are multiple consecutive transactions at non-low prices. These signals may be used, for example, as conditional statements input to a trading block such as a market maker block. The state block may also evaluate information such as whether the discontinuous event is a buy execution message or a sell execution message. The equations that can be used to specify the equation (which can be provided by the building block button) are "Instrument" (which provides the instrument associated with the discontinuous event), "Contract Price". (Provides the contract price associated with the discontinuous event), "Contract quantity" (provides the contract quantity associated with the discontinuous event), "Order quantity" (provides the order quantity associated with the discontinuous event) , "Order Price" (provides the order price associated with the discontinuous event), "Executed Quantity" (provides the accumulation of executions related to the order quantity), "Receiving Quantity" (at a specific order price) Provides the accumulation of non-executed order quantities), "transaction quantity" (provides the quantity of transactions executed on an exchange), "transaction price" (provides the price of transactions executed on an exchange) ) And "variables" (which provide the value of a specified user-defined variable, or the value of any other block output in the algorithm that is not part of a virtualized group block).
The branch block may receive the discontinuous event and evaluate the conditional statement on the discontinuous input. If the conditional statement is "true", the discontinuous event is provided in the first discontinuous output ("yes" path), and if the conditional statement is "false", the discontinuous event is in the second discontinuous output. Provided in ("No" route). The conditional statement may be provided in a continuous Boolean input. Alternatively, the conditional statement may be provided by a specified user-defined equation that evaluates a Boolean value. The specified equation may be modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select a branch block and enter the equation. Good. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. The branch block may be used, for example, to evaluate whether the discontinuous event is a buy execution event or a sell execution event. A "buy?" Building block button may be used to construct such an equation. Other equations available for use in specifying equations (which can be provided by the building block button) are "instruments" (which provide instruments associated with discontinuous events), "Contract price" (provides the contract price associated with the discontinuous event), "Contract quantity" (provides the contract quantity associated with the discontinuous event), "Order quantity" (provides the order quantity associated with the discontinuous event) (Provide), "Order Price" (provide the order price associated with the discontinuous event), "Run Quantity" (provide the accumulation of executions related to the order quantity), "Receiving Quantity" (specific "Provides an accumulation of non-executable order quantities at the order price", "Transaction quantity" (provides the quantity of transactions executed on an exchange), "Transaction price" (provides the price of transactions executed on an exchange)
The multiplexer block may receive a discontinuous event at a discontinuous input and provide this discontinuous event at a particular discontinuous output. For example, the multiplexer block may receive a discontinuous event from the order handler block and provide it on the appropriate discontinuous output of the multiplexer block based on the type of this discontinuity event (eg, fill, modify or delete). Good. Once deployed, the user may be prompted to specify for which discontinuous event type the output is provided. Alternatively, the multiplexer block may default to a default setting that provides output for any discontinuous event type. The specified discontinuous event type for which output is provided, such as a menu item or double-click that the user should be prompted to select a multiplexer block and specify a discontinuous event type while designing the algorithm. May be modified by using the action of. The multiplexer block may be used, for example, with an order handler block to manage orders.
The funnel block may receive discontinuous events on two or more discontinuous inputs and provide them in a single discontinuous output. The funnel block does not hold the discontinuous event and lets it pass to the output. The funnel block may be used, for example, with a state block that requires multiple inputs.
The sequencer block may guarantee orders for discontinuous events to pass through the output. The sequencer block may have one discontinuous input and two or more discontinuous outputs. When a discontinuous event is received at the input, the sequencer block sequentially provides this discontinuous event to each output. That is, in the processing of the received discontinuous event, the sequencer block first provides the discontinuous event to the first output, then the discontinuous event to the second output, and so on. This may allow the user to determine exactly which order block that receives the discontinuous input is updated in the algorithm. However, if multiple blocks are connected to the same discontinuous output of sequencer blocks, the order in which these blocks receive discontinuous events is not specified. This block is sometimes referred to as a sequence block.
The discontinuous minimum block may compare two discontinuous inputs and provide a continuous numerical output of the minimum value of the specified attribute (eg, transaction price, transaction quantity, etc.). When a discontinuous event is received on one of the inputs, the attribute value specified from this event is extracted and stored. The extracted value is compared with the recently stored values for other discontinuous inputs to determine which is the smaller value, and that value is provided in the continuous numeric output. If no discontinuous event is received on one input, the value extracted from the other input may always be treated as a larger value. As an alternative, the value of a particular discontinuous input may simply default to 0. The discontinuity minimum block may be a pass-through block, so that each discontinuity event received is emitted via the corresponding discontinuity output. The discontinuous minimum block may include a reset discontinuous input that, upon receiving an event, resets the stored value for each discontinuous input and updates the minimum output accordingly.
The discontinuous maximum block may compare two discontinuous inputs and provide a continuous numerical output of the maximum value of a specified attribute (eg, transaction price, transaction quantity, etc.). When a discontinuous event is received on one of the inputs, the attribute value specified from this event is extracted and stored. The extracted value is compared to the recently stored value for other discontinuous inputs to determine which is the larger value, and that value is provided in the continuous numeric output. If no discontinuous event is received on one input, the value extracted from the other input may always be treated as a larger value. As an alternative, the value of a particular discontinuous input may simply default to 0. The maximum discontinuous block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output. The discontinuous maximum block may include a reset discontinuous input that, upon receiving an event, resets the stored value for each discontinuous input and updates the maximum output accordingly.
Other blocks include, for example, min, max, round, decimal display, not, once true, number, moving average, conditional f (x), number f (x), mean, timer, note, random number. , Square root, logarithmic and dormant blocks may be included.
The smallest block may compare two continuous numeric inputs to determine which is the smaller value and output it. The smallest block may have a triangular shape with the text "MIN" in the middle, two continuous numeric inputs on the left and one continuous numeric output on the right.
The maximum block may compare two continuous numeric inputs to determine which is the larger value and output it. The largest block may have a triangular shape with the text "MAX" in the middle, two continuous numeric inputs on the left and one continuous numeric output on the right.
The rounding block may round the numbers provided by the continuous numeric input to the recent increments provided by the continuous numeric input to produce one continuous numeric output. The rounding block may be rounded to a recent integer if no increment value is provided. In addition, the user may specify one of three rounding block options: regular rounding, always rounding up, and always truncating. Regular rounding uses traditional rounding rules (for example, 0.5 is rounded up to 1 and 0.49 is rounded down to 0). Always rounding up rounds the value that exists between the two increments to a higher increment (for example, 2.1 is rounded up to 3 and 2 is rounded to 2). Always truncation rounds the value that exists between the two increments to a lower increment (for example, 2.9 is rounded down to 2 and 2 is rounded to 2). If no option is specified, the rounding block may default to, for example, regular rounding. The rounding block may have a rectangular shape with the text "rounding" in the middle, two continuous numeric inputs on the left and one continuous numeric output on the right.
The decimal display block may output numbers in decimal format using the numbers provided by the continuous numeric input and the instruments provided by the continuous instrument input. For example, a decimal display block wants the user to use a number block to feed a value such as a price to another part of the algorithm (perhaps as a variable) without having to calculate that value in decimal format. It may be used when doing so. Users may be accustomed to seeing the price of Instrument ZN at 117125, which may represent prices 117 and 12.5 / 32nds. The 117125 may be provided as an input with the instrument by the decimal display block, which transfers this number to the appropriate decimal format value (here 117.390625) used by the rest of the algorithm. Convert. The decimal display block may have a rectangular shape with the text "D2Dec" in the middle, one continuous instrument input and one continuous numeric input on the left, and one continuous numeric output on the right.
The NOT block performs logical negation of continuous Boolean inputs so that the output is "false" if the input value is "true" and the output is "true" if the input value is "false". You may. The NOT block has a rectangular shape on the left and an arch on the right, with a negative sign ("!" Or "-") in the middle, one continuous Boolean input on the left and one continuous Boolean output on the right. You may.
Once a true block has a continuous Boolean input of "true", it may provide a "true" continuous Boolean output for the life of the algorithm. The output value of a true block is "false" once until the input value is "true" at least once. Once the input value becomes "true", the true block always outputs the value "true" even if the input value changes thereafter. Once a true block may have a rectangular shape on the left and an arched shape on the right, with the text "T" in the middle, one continuous Boolean input on the left and one continuous Boolean output on the right. This block is sometimes referred to as the "once true, always true" block.
A "numeric" block provides a "true" continuous Boolean output if the value provided in a continuous numeric input is a number, and if the value provided is a "non-numeric" (NaN). You may output "false". The "numeric" block has a rectangular shape on the left and an arched shape on the right, with the text "IsNum?" In the middle, one continuous numeric input on the left and one continuous Boolean output on the right. May be good.
The moving average block adopts a data value (price or quantity, etc. may change over time) as a continuous numerical input, a fractional value as a continuous numerical input, and is designated as a continuous numerical output. A moving average over a fraction may be provided. The moving average block may record data values every second. For example, if the user wants to get a 1-minute moving average, the moving average block records 60 data points and averages them out for output. Further, the moving average block may adopt a continuous Boolean value indicating whether or not the input data value is valid. This input is optional and defaults to "true". If the data value is to be recorded (by default once per second), the moving average block checks to see if its valid input is "true". If "true", the data value is recorded as a data point. If the valid input is "false", the data value is not recorded as a data point. Further, the moving average block may adopt a discontinuous input which is a reset input. When a discontinuous event is received by the reset input, the recorded data points are abandoned. This results in a moving average output of 0 or "non-number" (NaN), depending on the data value recorded. The moving average block may also provide an OK continuous Boolean output that indicates whether enough data points have been recorded to fully calculate the moving average. The OK output is "false" until the required number of data points have been recorded, and "true" after that (until reset). For example, if the number of minutes entered provides a value of 20 (20 minutes moving average), 1200 data points (1 data point per second for 20 minutes) must be recorded before the OK output is "true". There is. The moving average block may also provide a continuous numerical output of the number of data points displaying the number of recorded data points. The moving average block is the text "MvgAvg" in the middle and 4 on the left.
The conditional f (x) block may evaluate a user-defined equation that provides a value for continuous Boolean output. Once placed, the user may be prompted to enter an equation to be evaluated. Alternatively, the conditional f (x) block may default to a default value such as "true". The specified equation uses an action such as a menu item or double-click that the user should be prompted to enter the equation by selecting the conditional f (x) block while designing the algorithm. May be changed by The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. In certain embodiments, the conditional f (x) block may refer to a value from the output of another block. The value may be referenced using the building block button 215, which specifies the block and output, or it may be provided to the continuous variable input of the conditional f (x) block. A conditional f (x) block has the text "f (x)" in the middle and no input on the left (if the value is not referenced in a user-defined equation, in which case the continuous input corresponding to each variable). Is provided), it may have one continuous Boolean output on the right side, a rectangular shape on the left side, and an arch shape on the right side.
The numeric f (x) block may evaluate a user-defined equation that provides a value for continuous numeric output. Once placed, the user may be prompted to enter an equation to be evaluated. Alternatively, the numeric f (x) block may default to a default value such as 0. The specified equation can be specified by the user while designing the algorithm, for example by using an action such as a menu item or double-click that should be prompted by the user to select a numeric f (x) block and enter the equation. May be changed. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. In certain embodiments, the numeric f (x) block may refer to a value from the output of another block. The value may be referenced using the building block button 215, which specifies the block and output, or it may be provided to the continuous variable input of the numeric f (x) block. The numeric f (x) block has the text "f (x)" in the middle and no input on the left (if the value is not referenced in a user-defined equation, in which case the continuous input corresponding to each variable is (Provided), may have one continuous numerical output on the right side, a rectangular shape on the left side, and an arch shape on the right side.
In certain embodiments, the conditional f (x) block and the numeric f (x) block may be merged into a single block, such as an f (x) block. The f (x) block may evaluate a user-defined equation that provides either a Boolean value or a number in the continuous variable output. Once placed, the user may be prompted to enter an equation to be evaluated. Alternatively, the f (x) block may default to a default value such as 0. The specified equation is modified by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select the f (x) block and enter the equation. May be done. The equation may be entered literally or, for example, using a building block button similar to the building block button 215 discussed above. In certain embodiments, the f (x) block may refer to a value from the output of another block. The value may be referenced using the building block button 215, which specifies the block and output, or it may be provided to the continuous variable input of the f (x) block. The f (x) block has the text "f (x)" in the middle and no input on the left (if the value is not referenced in a user-defined equation, in which case the continuous input corresponding to each variable is provided. It may have one continuous variable output on the right side, a rectangular shape on the left side, and an arch shape on the right side.
The averaging block may generate one continuous numeric output by averaging the values of two or more continuous numeric inputs. For example, the average block may have 10 inputs. As another example, the average block may start with one input and a new input may be dynamically provided each time a connection is made to the average block input. The values of the inputs are summed and then divided by the number of inputs that provide the values to provide the output. The average block may have a rectangular shape with the text "AVE" or "AVG" in the middle, two or more continuous numeric inputs on the left and one continuous numeric output on the right.
The timer block may provide continuous numerical output of hours, minutes and seconds. For example, the time may be the current time. The current time may be, for example, the time in the computing device that provides the trading interface to the user, or the current time in the algorithm server. As another example, this time may be from the time the algorithm starts execution. As another example, this time may be the time since the start of the current trading session. As another example, this time may be from 12 amCST in the current trading session. As another example, this time may be the time provided by the exchange. The timer block may have a rectangular shape with the text "TIMER" or clock symbol in the middle and three continuous numerical outputs on the right.
The note block may provide a text box for the user to enter comments and notes regarding the algorithm being designed. NOTE The block may have no inputs or outputs. Once placed, the user may be prompted to enter text in the note block. Alternatively, the note block may default to a default value such as "Add note here". The specified value may be changed while designing the algorithm by the user, for example, by using an action such as a menu item or double click that should be prompted to select a note block and enter a value. Good. NOTE The block does not affect the operation of the algorithm. Note The block may have a rectangular shape with a text value displayed in the middle.
The random number block may provide random numbers to the continuous numeric output. Random numbers may be specified to be integer or floating point values when the random number block is placed or set later. The random number block may default to providing an integer value. The random number may be between the minimum value specified by the continuous numerical input and the maximum value specified by the continuous numerical input. This may default to 0, for example, if no minimum input is provided. If no maximum input is provided, this may default to the maximum integer supported by the computing device for integer output, or to 1 for floating point output. The random number block may also have a discontinuous input for signaling when a new random number should be provided. If no discontinuous input is provided, the random number block may provide a new random number, eg, every second. The random number block may be a pass-through block, so that each discontinuous event received is emitted via the corresponding discontinuous output. The random number block has a square shape with a question mark symbol ("?") Or text (RAND) in the middle, two continuous numeric inputs and one discontinuous input on the left and one continuous numeric output on the right. May be good.
The square root block may provide the square root value in the continuous numeric output with respect to the value provided in the continuous numeric input. If the input is negative, the output may be "non-number" (NaN). The square root block is the square root symbol in the middle<img file="JP6775615B2_D0001.tif" />It may have a triangular shape with one continuous numeric input on the left and one continuous numeric output on the right.
The logarithmic block may provide a logarithmic value in the continuous numerical output with respect to the value provided in the continuous numerical input. The base value of the logarithm may be provided in the continuous numeric input. If no base value is provided, this may default to, for example, the natural logarithm. The logarithmic block may have a square shape with the text "logarithmic" in the middle, two continuous numeric inputs on the left and one continuous numeric output on the right.
The pause block may pause the entire algorithm when a discontinuous event is received on the discontinuous input, or when the value provided on the continuous Boolean input becomes "true". In certain embodiments, the algorithm may resume execution if the Boolean input value becomes "false" again. In certain embodiments, the algorithm must be manually restarted once it has been paused due to a pause block. The dormant block may be octagonal with a red background, text "stop" in the middle, and one continuous Boolean input and one discontinuous input on the left.
The instructions or logics that represent the algorithm (referred to herein as programming code) are generated on the basis of the algorithm's definition. In certain embodiments, the programming code is source code (human and / or compiler-readable text) that can be subsequently compiled. In certain embodiments, the language of the programming code is an intermediate language. In certain embodiments, the programming code comprises machine executable instructions. In certain embodiments, the generation of programming code involves compiling the generated source code and / or intermediate language code. In certain embodiments, the generation of programming code does not include compiling the generated source code and / or intermediate language code, and such compilation is a separate process. The generated programming code (if appropriate after compilation) may then be simulated and / or used to trade according to the defined algorithm. Where the programming code is discussed herein to be executed, executed and / or simulated, it is appropriate that the generated programming code be executed, executed and / or simulated. If so, it is assumed that additional compilation has been performed.
In certain embodiments, programming code is generated as the algorithm is designed. Note that while the algorithm is designed, the definition of the algorithm may change as blocks and / or connections are added, modified and / or removed. In certain embodiments, the programming code is automatically generated when the algorithm definition changes. In certain embodiments, the programming code is generated at the time requested by the user.
In certain embodiments, the programming code is generated by a component of the algorithmic trading application of trading interface 310 on the client device. In certain embodiments, the programming code trades algorithms in another device, such as, for example, an algorithm generation device, an algorithm server similar to the algorithm server 302 described above and / or a gateway similar to the gateway 120 described above. Generated by the components of the application. In certain embodiments, the programming code is generated by two or more components. For example, multiple components of an algorithmic trading application may work together to generate code. Such components may be specialized, for example, to generate different aspects or functions of programming code.
In certain embodiments, the programming code is generated by two or more devices. For example, the programming code may be generated by the client device and the algorithm server. The programming code generated on the basis of the algorithm definition may differ based on which component or device produces it. For example, the programming code generated on the client device may be optimized for execution by the client device and / or may not include programming code generated on the algorithm server (eg, it may not include user interface related functionality). It may include functions that are different from those (eg, user interface related functions). For clarity, unless otherwise noted, the following discussion is about generating programming code on a client device, but similar measures should be taken when programming code is generated on another device, such as an algorithm server. Should be understood.
In certain embodiments, the programming code is generated object-oriented using programming languages such as C # and the .NET 4.0 framework.
In certain embodiments, programming code is generated by traversing each block and connection in the algorithm definition. The programming code is generated block by block. When generating programming code, some blocks may be primitive variables. For example, an adder block can be a floating point variable whose values are set to be the sum of the values of the outputs connected to the input of the adder block, even if the sum is recursively determined. Good. Other blocks that may have more complex functionality may be generated as subclasses derived from the base class. The base class may provide core functionality associated with the corresponding block. The generated subclass may then override the virtual method with the return value in order to provide the core functionality of the base class with values specific to the block in which the programming code is being generated. For example, the market maker block located within the design canvas area 311 may have generated programming code that is a subclass of the base market maker class. Subclasses override the virtual method to get values for the various inputs of the marketmaker block and to specify whether the marketmaker block was set up for buying or selling. You may. Unlike the basic blocks discussed above, marketmaker blocks are trading blocks that provide more complex functionality.
Continuous connections between blocks specify how the connected output and input values relate to each other. Continuing with the adder example above, the floating point value that represents the output of the adder block is the sum of the values of other primitive variables (representing other blocks / outputs) that are connected to the continuous input of the adder block. It may be set to be. In certain embodiments, the generated programming code is a continuous connection so that multiple blocks with continuous connections (which generate primitive variables) can be condensed into a single expression without the use of multiple intermediate parameters. May be flattened using.
Discontinuous connections between blocks are used to generate event generators and event handlers so that the appropriate method (handler) is called when a discontinuous event is generated. Discontinuous events are sent from the event generator to the event handler for processing.
Upon execution, the algorithm responds to actions that change the state of the algorithm. Actions may also include external events such as market events (eg price updates, quantity updates, order confirmations, transaction confirmations, execution confirmations or transaction notifications) and timer events (eg from system clocks or alarms). Good. These external events result in discontinuous events such as order confirmation discontinuous events, transaction confirmation discontinuous events, execution confirmation discontinuous events or transaction notification discontinuous events, and / or the price of the instrument. Continuous values such as value or quantity value may be updated. Actions may also include internal events such as discontinuous events generated by blocks in the algorithm or changing continuous values.
When an internal or external discontinuity event occurs (for example, a transaction confirmation discontinuity event or a generator block raises a discontinuity event), each associated block in the algorithm is specialized in that block is associated with the event. The event handler method is called so that the above functions can be executed. Event handlers may be evaluated in an unspecified order. For example, event handlers may be evaluated based on the order in which their individual blocks are placed in the algorithm definition. The processing by the event handler is to execute the function of the block based on the received event, update the continuous output value, and generate a discontinuous event and output it to other connected blocks. May include providing.
When internal or external contiguous values change (for example, market data is updated or system clock time changes), each associated block (downstream block) connected directly or indirectly to the data source has new data The value is updated to reflect. Primitive variables that are the result of some blocks are assigned new values, for example.
If the continuous output value is updated by either a discontinuous event or a continuous value change, each block directly or indirectly connected to receive the updated value is added to the list of blocks to be processed. .. When the blocks involved in the external event complete their processing, the list of blocks is processed so that these blocks can then act in response to the internal event. Internal events are processed in the same way as external events. This process may then be repeated as the process of each block creates new changes in the state of the algorithm.
3D-1 to 3D-7 show examples of programming code generated by a given embodiment. Note that the programming code shown is merely a portion of the programming code that can be generated and is for illustrative purposes only, and is therefore simplified to emphasize certain functionality for clarity. I want to be.
The programming code may be generated even if no blocks are placed in the design canvas area 311 as shown in Figure 3D-1. The generated programming code contains a new class ("CustomAlgorithm0") that represents the algorithm under design. This new class is a subclass of the algorithmic class and provides the basic interface and functionality for running algorithms with algorithmic trading applications. The CustomAlgorithm0 class may override the virtual method of this algorithm class so that the functionality specific to the algorithm under design can be incorporated and executed in the framework of the algorithmic trading application.
Continuing the description of this example, additional programming code may be generated when the block is placed in the design canvas area 311 as shown in Figure 3D-2. As discussed earlier, some blocks can be primitive variables, and the continuity connection between them represents how they relate to each other. For example, as shown, the design canvas area 311 contains two constant blocks ("ConstantNumberBlock0" and "ConstantNumberBlock1") and an adder block ("AdderBlock0"). Note that the blocks are not connected. The marked parts of the generated programming code indicate that these basic blocks are represented in the programming code as primitive variables (of the "double" type).
As shown in Figure 3D-3, the connection is from ConstantNumberBlock0 and ConstantNumberBlock1 to AdderBlock0. The connection manifests the relationship between these blocks. The marked part of the generated programming code indicates that the value of AdderBlock0 is equal to the sum of the value of ConstantNumberBlock0 and the value of ConstantNumberBlock1. This is because the function represented by the adder block is to add the values of the two inputs.
As shown in Figure 3D-4, the market maker block is located in the design canvas area 311. Unlike the basic blocks discussed above, marketmaker blocks are trading blocks that provide more complex functionality. The generated programming code adds a new class ("CustomMarketMaker0") that represents the functionality of the particular marketmaker block in which it is located. CustomMarketMaker0 is a subclass of Marketplace that provides the basic functionality of the marketmaker block. The CustomMarketMaker0 class may override the virtual method with the return type of the Marketplace class so that the functionality specific to the placed marketmaker block can be incorporated and performed in the framework of the algorithmic trading application. In this case, CustomMarketMaker0 gets the values of the various inputs of the marketmaker block, overriding the method called by logic in the Marketplace base class. As shown in Figure 3D-5, the quantity input of the placed marketmaker block is connected to the output of the adder block discussed earlier. The marked part of the generated programming code indicates that the customMarketMaker0 class virtual method "GetQty" has been overridden to return the value of AdderBlock0.
Continuing the description of this example, as shown in Figure 3D-6, there is a connection between the discontinuous output and the discontinuous input. Specifically, the connection was made between the discontinuous contract output of the market maker block and the reset input of the value integrator block. The value multiplier block is a discontinuous block, and a new class ("CustomValueAccumulator0") has been added as well as the trading block (not shown). The marked part of the generated programming code is that new subclasses ("CustomMarketMaker0" and "CustomValueAccumulator0") are instantiated, and that the MarketMakerBlock0 event "DiscreteObjectGenerated" is CustomAlgorithm0 ("InterceptOrderMessage") and ValueAccumulatorBlock0 ("CustomValueAccumulator0"). Indicates that it is concatenated with the event handler of "ProcessResetMessage"). Therefore, if MarketplaceBlock0 has a trade message, it will fire the DiscreteObjectGenerated event and notify all concatenated handlers. In this case, when a notification arrives at the ProcessResetMessage handler, it resets the multiplier value to 0.
Continuing the description of this example, as shown in Figure 3D-7, there is a connection between the instrument block ("Simple InstrumentBlock0") and the instrument attribute block ("InstrumentFieldBlock0"). .. The instrument block is generated to be an instance of the "InstrumentSnapshot" class that updates its continuous output based on the market data received for the instrument "ESZ0". The InstrumentSnapshot class provides a membership variable or characteristic that can be referenced to obtain the corresponding value for that attribute of an instrument. For example, when "SetAllVariables" (sets all values in the algorithm) or "HandleUpdate" (sets the values affected by a particular continuous value update) is called, the instrument attribute block will have that value. Is set to be the ".Bid" characteristic of the instrument block.
FIG. 3E shows a trading interface 310 according to a predetermined embodiment. A given block may be designated as a "variable". For example, constant blocks, constant Boolean blocks, and instrument blocks may be specified as variables.
The variable area 313 prepares for the modification of the variable block. The variable area 313 displays the block name of each variable and its default value. The variable area may be selected to change the block name of the variable and / or its default value. Variables are sometimes referred to as algorithm parameters.
As shown, the design canvas area 311 contains two blocks designated as variables: instrument block 321 and constant block 322. The block may be specified as a variable, for example, when or after it is placed. For example, a block may be selected using a cursor, and then a menu option may be selected to specify the block to be a variable. The blocks specified as variables may be represented by, for example, different colors, edges, backgrounds, patterns and / or text. In this figure, the text "Variable" is added to the displayed block name.
As discussed earlier, the variable area 313 includes a name column 323 with an input for each variable block 321 and 322 and a default value column 324 with a corresponding default value input for each variable block. For example, instrument block 321 is named "InstrumentBlock0" and has a default value of "ESZ0", and constant block 322 is named "ConstantBlock0" and has a default value of "5".
The user can change the default value of the variable block by selecting the default value input in column 324, so that the new default value will be used in the algorithm evaluation. Similarly, the user can rename individual variable blocks by selecting the name input in name column 323. Variable blocks 321 and 322 may allow the user to manipulate the behavior of the algorithm rather than the underlying logic, for example, by changing the values of the variable blocks that act as parameters of the algorithm.
Control area 314 provides controls for use in designing the algorithm. The control area 314 may include a play button and a pause button for starting and pausing the algorithm simulation. Algorithm simulations may be used to show how the logic of an algorithm behaves. Further, the control area 314 may include a generate button (not shown) that causes the programming code to be generated on the basis of the algorithm. The generate button may be used when the programming code is not automatically generated based on the algorithm change. This is desirable when the algorithm under design is complex and the generation of each modified programming code of the algorithm (and, if appropriate, subsequent compilation of this programming code) is undesirable and takes a long time. There is. In certain embodiments, control area 314 may include a compile button (not shown) that compiles programming code generated on the basis of the algorithm. The compile button may be used when the programming code is not automatically generated and / or compiled based on algorithmic changes. This may be desirable if the algorithm being designed is complex and it takes a long time to compile the programming code after each modification of the algorithm.
FIG. 3F-FIG. 3G shows a trading interface 310 according to a predetermined embodiment. The trading interface 310 provides a live feedback function. The live feedback feature provides a display of the values for a particular block within the design canvas area 311. For example, live feedback values may be displayed for one or more inputs and / or outputs of the block. The live feedback value may be displayed, for example, in relation to the block or the corresponding input and / or output. Live feedback may be updated each time the input or output value of the block changes. Changes in the output of one block can result in (directly or indirectly) changing the output of another block that takes the output of this first block as input, which updates the live feedback of both blocks. Please note that the result will be.
As shown in Figure 3F, various blocks 331 are placed in the design canvas area 311. For each output of block 331, live feedback 332 is provided indicating the value of the output. Note that no live feedback is provided as block 333 is a numeric block and the output value is shown on the display of block 333 itself. In certain embodiments, live feedback is provided for one or more inputs of a particular block placed. In certain embodiments, live feedback is provided with respect to both the input and output of the particular block in which it is placed. In certain embodiments, live feedback is provided for all blocks within the design canvas area 311.
The instrument block live feedback shows the value "GCJ1". The live feedback of the instrument attribute block set to provide the buy quantity displays the value "3", indicating that the buy quantity of the instrument GCJ1 is 3. The live feedback of the adder block shows a value of 13, which is the sum of the two input values 3 (from the instrument attribute block) and 10 (from the first digit block). The live feedback of the division block shows a value of 6.5, which is the result of dividing the first input value 13 (from the adder block) by the second input value 2 (from the second digit block). is there.
Live feedback may not be provided for a given block unless the algorithm is simulating. For example, as shown in Figure 3G, the output of Marketmaker Block 335 does not provide live feedback. This is because the marketmaker block 335 does not work and therefore does not interact with the market unless the algorithm is running (eg, simulating). Therefore, the market maker block 335 does not provide a continuous value based on its behavior (because it is not working) and does not generate discontinuous events (again, because it is not working). Also, live feedback is not provided for the output of value extractor block 336. This is because the value extractor block 336 has a discontinuous input, so its output has a value only when a discontinuous event is received. However, discontinuous events will not be received unless the algorithm is running.
The live feedback value to be displayed is provided by the algorithm itself. For example, the programming code generated for the algorithm under design may include additional instructions for updating the display of a trading interface, such as trading interface 310. In certain embodiments, the programming code generated for the algorithm does not include additional instruments for updating the display of the trading interface, for example, because the algorithm server 302 or the like may not have a trading interface. .. As shown in Figure 3D-2 and Figure 3D-3, the method "SetAllVariables" calls the method "SendUpdate" when called. Method SendUpdate provides the user interface with the identification of the block to be updated, the specific output exponent and value to be updated (in this case, the value of the adder block). Therefore, every time the block value changes, an update is provided to the user interface to update the live feedback. The method SendUpdate may also be called by the base class of the block that generates the derived class to provide the update value to the user interface. Similarly, as shown in Figure 3D-6, the event handler "InterceptOrderMessage" is registered to be called when the event "DiscreteObjectGenerated" occurs. Method InterceptOrderMessage provides the user interface with notification of the corresponding discontinuous event. Therefore, the user interface can provide live feedback each time this discontinuous event occurs.
During execution of the algorithm (such as during simulation), live feedback may be provided for all blocks in the design canvas area 311. Since the discontinuous event occurs at a specific time point, when the event occurs, the discontinuous event occurrence indicator may be displayed. For example, discontinuous inputs and / or outputs may be flushed to change color, size, or shape when a discontinuous event occurs at the inputs and / or outputs. As another example, the connection between the discontinuous input and the discontinuous output may be flushed to change color, size or shape when a discontinuous event is provided through the connection. As another example, an animation may be provided along the connection to represent that the discontinuous event is being provided from the output to the input along the connection. The animation may be, for example, an icon such as a red circle moving along the connection, or the connection may be pulsating.
The live feedback feature provides feedback to the user during algorithm design and algorithm execution. Live feedback may include the safety and integrity of the operation of the algorithm, general trends and potential losses / benefits, and allow the user to evaluate how the algorithm logic behaves.
FIG. 3H-FIG. 3L shows a trading interface 310 according to a predetermined embodiment. The trading interface 310 provides a safety feature to reduce potential errors when the algorithm is designed.
As shown in FIG. 3H, the instrument block 341 is located in the design canvas area 311. However, no instrument was designated when the instrument block 341 was placed. This is an invalid setting because the instrument block cannot output the instrument name unless the instrument is specified. Near instrument block 341, a warning indicator 342 (in this case, an icon with an exclamation mark ("!") In a red circle) indicating that a problem exists, and the cursor is instrumented. If you place it near the ment block 341, the problem description 343 will be displayed. In certain embodiments, other (or additional), for example, the background of the design canvas area 311 is lightly colored in red and / or a warning or error message is displayed in the status bar to indicate the problem. Indicator) may be displayed.
As shown in Figure 3I, the instrument attribute block 344 is located in the design canvas area 311. However, the instrument attribute block 344, which is set to provide the best bid price for the instrument, is not provided with the required input, i.e. the instrument name that should provide the best bid price. .. That is, the instrument attribute block 344 is not connected to the instrument block (or any other block that may provide the instrument name). Therefore, the algorithm definition is invalid. Again, a warning indicator and exclamation mark are displayed, as in Figure 3H.
As shown in Figure 3J, the instrument attribute block 344 and the market maker block 345 are located in the design canvas area 311. The user is trying to connect the output of instrument attribute block 344 (continuous output with a numeric type) to the instrument input of marketmaker block 345 (continuous input with instrument value type). These input and output value types are non-conforming, thus invalidating the algorithm definition. An indicator 346 (in this case, a circle with a slash) is displayed on the attempted connection line to indicate that the connection is invalid. In addition, description 347 is also displayed. Similar feedback may be provided when a connection is attempted between a continuous output and a discontinuous input.
As shown in Figure 3K, adder block 348a and adder block 348b are located in the design canvas area 311. The user is trying to connect the output of adder block 348b to the input of adder block 348a. However, the output of adder block 348a is already connected as input to adder block 348b. Allowing the connection being tried results in a circular dependency in the generated programming code. Specifically, if you try to generate programming code to determine the value of adder block 348a, you end up with an infinite loop. Therefore, such an algorithm definition is invalid, so this connection is shown as invalid and a description is displayed, similar to the feedback specified in Figure 3J.
As shown in FIG. 3L, the design canvas area 311 contains the generator block 349a, the funnel block 349b, the value extractor block 349c, and the value integrator block 349d. The user is trying to connect the discontinuous output of the value multiplier block 349d to the discontinuous input of the funnel block 349b. However, the funnel block 349b, the value extractor block 349c, and the value integrator block 349d are each pass-through blocks, so that each discontinuous event received is emitted via the corresponding discontinuous output. Therefore, if a discontinuous event is provided by generator block 349a (also connected to funnel block 349b), it will pass through each connecting block. Allowing the connection being tried results in an infinite loop in the generated programming code. Specifically, the generated programming code infinitely sends the discontinuous event to each block to be processed next when processing the discontinuous event provided by the generator block, in this case, the processing. Includes providing a discontinuous event to the next block in the cycle. Therefore, such an algorithm definition is invalid, so this connection is shown as invalid and a description is displayed, similar to the feedback specified in Figure 3J.
In certain embodiments, warnings and / or error messages may be provided in separate areas of trading interface 310. This allows the user to immediately see all the outstanding warnings and errors, for example, instead of examining each block individually.
FIG. 3M-FIG. 3R shows a trading interface 310 according to a predetermined embodiment. Trading interface 310 provides grouping capabilities that allow, for example, to reduce clutter, enable reuse of algorithmic parts (including generation of modules that can be shared between algorithms), and enable virtualization capabilities. .. Reducing clutter and reusing parts of the algorithm can lead to better algorithms by reducing the possibility of mistakes in algorithm design. The advantages of the virtualization function will be discussed below.
As shown in Figure 3M, the definition of a simple scalping algorithm is designed. Roughly speaking, the scalping algorithm buys at the best bid price and then sells at a trade increment one above the trade price to make a profit of one trade increment per unit of buy / sell. More specifically, the algorithm includes a buy market maker block 351 and a sell market maker block 352. The buy market maker block 351 is provided with the instrument to buy ("ESZ0") specified by the instrument block. The buy market maker block 351 is provided with a buy price specified by the instrument field block that gives the best bid price for the instrument. The buy market maker block 351 is provided with a fixed quantity of 10 to buy, specified by a number block. When the buy market maker block 351 receives the execution confirmation of the buy order being accepted, a discontinuous event occurs.
The sell market maker block 352 activates the sell order to cover the position taken by the buy market maker block 351. The Sell Market Maker Block 352 is provided with the same instrument ("ESZ0") to sell. The Sell Market Maker Block 352 is given the minimum price increment of the instrument (provided by the Instrument Field Block) at the Contract Price (By the Value Extractor Block, the Buy Market Maker Block receives the execution confirmation. The selling price specified by the adder block that adds to (provided from the discontinuous event generated by 351) is provided. The sell market maker block 352 is provided with the sell quantity specified by the adder block that provides the cumulative quantity being bought by the buy market maker block 351. It is extracted from the discontinuous event that occurs when the execution confirmation is received.
Therefore, during the execution of the algorithm, the buy market maker block 351 buys the quantity 10 at the best bid price and sells the quantity 10 (perhaps by multiple sell orders) at the contract price plus the minimum price increment.
As shown in Figure 3N, the blocks associated with covering the logical part of the algorithm are selected by drawing a box 353 around them. Other user interface techniques may be used to select the block of interest to the user, for example by pressing a shift or control key in combination with a cursor.
Once blocks are selected, they may be grouped by actions such as selecting menu items.
As shown in FIG. 3O, the grouped blocks are then displayed with the block thumbnail image internally contained within the group block 353. Group block 353 reduces clutter in design canvas area 311 by reducing the number of blocks and connections shown. In addition, group blocks may be stored in the module's library so that they can be loaded into another algorithm and reused. Group blocks are sometimes referred to as grouped blocks. The blocks within a group block may be referred to, for example, as part of a defined algorithm, sub-algorithm or subroutine.
The group block 353 may be generated with an input 354 whose value is provided by the output of a block that does not exist within the group block 353, which corresponds to the input of the block within the group block 353. For example, as shown in FIG. 3O, the group block 353 has a continuous instrument input and a discontinuous input. The continuous instrument input corresponds to the continuous instrument input of the sell market maker block 352 and the instrument field block that determines the minimum price increment. The discontinuous input corresponds to the discontinuous input of the adder block and the value extractor block.
The group block 353 may be selected, and then the blocks contained in the group block 353 may be edited using actions such as selecting a menu item or double-clicking. As shown in FIG. 3P, a new window with a design canvas area similar to the design canvas area 311 may be displayed and operated in the same manner. Group block 353 includes new input blocks 355 and 356 that correspond to the inputs of group block 353. The input block 355 corresponds to the continuous instrument input of the group block 353, and the input block 356 corresponds to the discontinuous input of the group block 353. Input blocks 355 and 356 each have a single output that provides the values provided for the individual inputs of group block 353.
Although none of the blocks in the group block 353 has an output connected to a block outside the group block 353, it is not shown in FIG. 3P, but the group block may include an output block. Similar to the input block discussed above, the output block corresponds to the output of the group block. A block within a group block that has an output connected to an output block provides a value to a block outside the group block that is connected to the corresponding output of the group block.
When designing a group block, the input block and the output block may be arranged to generate the input or output of the group block. Once deployed, the user may be prompted to specify the type of input or output. Alternatively, the input or output block may default to a default type such as a continuous number. The type of input or output block can be selected by the user while designing the algorithm, for example by using an action such as a menu item or double click that should be prompted to select the input or output block and enter the type. May be changed. Similarly, the user may specify the name of an input or output block (and thus the corresponding input or output of a group block).
The group block may include another group block. This nesting of group blocks expects to reduce clutter and potentially increase the reusability of various parts of the algorithm.
When generating the program code, the group block is generated as a subclass of the algorithm class nested within the main CustomAlgorithm0 class of the algorithm under design. If a group block is nested within another group block, the generated programming code will nest each generated subclass as well. In addition, any non-primitive block is declared and defined in its recent group block parent. So, for example, if a group block is nested to a depth of 3 levels of group block and it has a market maker block (an example of a non-primitive block) inside, then the subclass of the market maker block has 3 levels. It exists in the algorithm class derived by depth.
Returning to the scalping algorithm discussed earlier, this algorithm is flawed, as shown in Figure 3M. Recall that the purpose of the scalping algorithm is to buy at the best bid price and then sell at a trade increment one above the trade price to make a profit of one trade increment per unit of buy / sell. If the buy market maker block 351 receives a single fill for a total of 10 buy orders placed, the algorithm works as intended. However, if two or more execution confirmations are received at two or more price levels, the algorithm will not work as desired. For example, suppose the buy market maker block 351 places a buy order with a quantity of 10 at the best bid price of 114125. Then, for the quantity 3, the first contract confirmation is received (thus, the target of the first contract is the quantity 3 at the contract price 114125). In response to this contract, Sell Market Maker Block 352 places a sell order with a quantity of 3 at a price of 114150 (114125 (contract price) + 25 (minimum price increment)). Now assume that the best bid price drops to 114100. Then, the buy market maker block 351 reassigns the currently accepted order to the new (and this time cheaper) best bid price for quantity 7. Then, for quantity 7, a second contract confirmation is received (thus, the target of the second contract is quantity 7 at the contract price 114100). Therefore, the behavior of the scalping algorithm is to place a first sell order at a price of 114150 (114125 + 25) for a quantity of 3 (covering the first fill) and a second sell order (second). It is desirable to do it at a price of 114125 (114100 + 25) for a quantity of 7 (covering the contract).
However, the algorithm shown in Figure 3M does not place proper orders to achieve the desired behavior. Upon receipt of the first contract, Sell Market Maker Block 352 places a first cover order to sell quantity 3 at a price of 114125 + 25. However, if the second fill is received before the first cover order is filled, it will be updated to quote from the adder block (updated to reflect that quantity 10 has already been filled). The selling market maker block 352, which receives a large quantity, places a cover order for a quantity of 10 at a price of 114100 + 25 (latest contract (second contract) price plus minimum price increment). Inevitably, the first execution is not covered at the desired price (this is an unintended and / or undesired behavior). In this case, if the cover order is fully filled, the total quantity 10 of the cover order is the same, even if the target of the algorithm's desired behavior is the cover order that should be placed at a price and quantity specific to each filled received. It is executed at the price.
The virtualization capabilities of Trading Application 300 address this type of problem. A group block may be selected, and then an action such as selecting a menu item may be used to specify that the group block is to be virtualized. As shown in Figure 3Q, the group block 353 is virtualized, which is shown by changing the boundary of the group block 353 from a solid line to a dashed line. In certain embodiments, group blocks may be shown to be virtualized in other ways, such as by adding text to the block name, changing the border color, background color or background pattern.
Instances of the virtualized group block are created for each discontinuous event provided to the virtualized group block. That is, each time a discontinuous event is received in the virtualized group block, a new instance of the virtualized group block is generated to handle the discontinuous event. This addresses the desirable behavior discussed above that each discontinuous event is treated by the logic of a group block on the basis of information specific to that discontinuous event. Continuing the description of the above example, however, in the context of virtualizing group block 353, each discontinuous event generated by buy market maker block 351 for execution results in , A new instance of virtualized group block 353 is created to handle that particular discontinuous event.
Therefore, the group block to be virtualized must have a discontinuous event input, since the one that creates a new instance informs the virtualized group block of the discontinuous event. Once a virtualized group block is instantiated, that particular instance will no longer receive discontinuous events from outside its scope (ie, from blocks that do not exist within the virtualized group block). Instead, any subsequent discontinuous event from outside the scope of the virtualized group block will create a new instance of the virtualized group block. However, discontinuous events may still occur and be handled by blocks within the virtualized group block, so discontinuous events occurring inside the virtualized group block are virtualized group blocks. May be provided for discontinuous inputs. Figure 3R conceptually shows how the algorithmic logic works when the buy market maker block 351 is generating three discontinuous events. The three instances of group block 353 are instantiated in response to each of the three discontinuous events from buy marketmaker block 351. The algorithm shown is effectively just showing a single virtualized group block 353 as shown in Figure 3Q, and the three instances shown in Figure 3R are just groups. Note that it is shown to represent the concept of block virtualization. In certain embodiments, the number of instances of the group block may be displayed. For example, the number of instances may be displayed graphically by showing a stack of virtualized group blocks in a manner similar to that shown in Figure 3R, in which case the size of the stack is instantiated. Represents the number of virtualized group block instances that have been created. As another example, a
Moreover, a virtualized group block cannot have a continuous output (although it can have a discontinuous output) because the value of the output, such as the continuous output, is not defined semantically. This is because there may be more than one instance of the virtualized group block (or the instance may not exist if the discontinuity event for it has not yet been received), so this way Continuous output can have different values at the same time, or it can be due to the fact that there are no values at all. In addition, a virtualized group block may not contain a block designated as a variable, because the variable should not "exist" until the virtualized group block is instantiated.
The virtualized group block may include another group block or another virtualized group block in the same way that a group block can be nested as discussed above.
When generating the programming code, the virtualized group block is generated as a subclass of the algorithm class like the non-virtualized group block discussed above. However, if the main CustomAlgorithm0 class, which is a list of initially empty virtualized group block subclasses, is retained, and discontinuous events are provided to the subclasses corresponding to the virtualized group block. Instead of being instantiated if it is, a new instance of the virtualized group block subclass is created.
The network connection between the client device and the algorithm server can be cut off unexpectedly. For example, an Internet Service Provider ("ISP") used by a client device to connect to an algorithm server may experience a router failure or physical disconnection of a communication link, which causes the client device and algorithm server. Communication with and may be interrupted. As another example, an intermediate node in the network can fail, also blocking communication between the client device and the algorithm server. As another example, the client device can go down and lose its connection to the algorithm server. In the current system, if such a connection is broken, the algorithm either stops or continues running without recognizing that the connection is broken. In the former case, the trader may be left in an open position that cannot easily (or possibly at all because the connection is down). In the latter case, the trader may not be able to modify the parameters of the algorithm, shut down or stop the algorithm, which may no longer be working properly or may be disproportionate to state changes in the market. Often, the trader may want to run an algorithm that can be extremely dangerous, so that it can be turned off immediately or the parameters can be changed.
In certain embodiments, one or more blocks can be designated to recognize the state of connection between the client device and the algorithm server. For example, once deployed, the user may be offered an option to specify that the block continues to execute even if the connection between the client device and the algorithm server that executes the algorithm is lost. This option may also be specified by selecting a block and using actions such as menu items or keyboard commands. Using the default, the algorithm may pause or stop when the connection between the client device and the algorithm server is lost. In certain embodiments, the entire algorithm is specified to continue execution even if the connection between the client device and the algorithm server that executes the algorithm is lost.
For example, the market maker block may have an option to keep the orders generated by the market maker block in the market even if the connection between the client device and the algorithm server is cut off. The marketmaker block used in the hedging or cover ordering part of the algorithm is due to another part of the algorithm, even though some of the algorithms that place these orders are no longer running due to a broken connection. The positions held may be set in this way so that they are hedged or covered as desired.
In certain embodiments, an input block that provides a continuous Boolean output representing the state of connection between the client device and the algorithm server may be added to the algorithm under design. The block may then take the value from this connection state input block as input to control its behavior. For example, the connection state input block is connected to the conditional input of the market maker block so that the market maker block places an order only if the connection state is "true" (indicating that it is connected). You may.
The algorithm may be stored as defined in trading interface 310. The algorithm may also be given a name (eg, during algorithm construction and / or when the algorithm is saved). Thus, the saved algorithm may later be called up or referenced by trading interface 310 or another trading interface. For example, the saved algorithm may be loaded by trading interface 310 so that it can be edited or reused for another order. As another example, the saved algorithm may be referenced as one order type from another trading interface as described below.
The components, elements and / or functions of the trading interface 310 discussed above may be implemented alone or in combination in various forms, for example as an instruction set in hardware, firmware and / or software. Certain embodiments are provided as an instruction set that resides on a computer-readable medium such as memory, a hard disk, a CD-ROM, a DVD, an EPROM, and / or a file server for execution on a general purpose computer or other processing device. You may. IV. Algorithm launch and management
A predetermined embodiment prepares for the initiation of an order to be managed as an order type by the selected algorithm. A predetermined embodiment prepares for the initiation of an order to be managed by a user-defined trading algorithm selected from the price axis. A predetermined embodiment prepares for changing the variables of the algorithm while the algorithm manages an order. A predetermined embodiment prepares for manually modifying an order managed by an algorithm. A predetermined embodiment provides for assigning an algorithm to manage an unmanaged order to that order. A predetermined embodiment provides for displaying on the price axis the accepting orders managed by different user-defined trading algorithms.
4A-4F show a trading interface according to a given embodiment. As shown in FIG. 4A, the trading interface 410 is an order ticket that allows the stored algorithm to be selected as the order type. The stored algorithm may be stored, for example, using a trading interface similar to the trading interfaces 200 and 310 discussed above.
The saved algorithm may be selected using the selection interface 415, which, as shown, is a drop containing both standard order types (limits and outcomes, etc.) as well as the saved algorithm. Provide a down list. In certain embodiments, the selection interface 415 includes other elements for selecting from the available stored algorithms. For example, selection interface 415 may open a file navigator to browse for a particular algorithm. As another example, selection interface 415 may include a tree view of stored algorithms that are hierarchically classified based on the type of algorithm.
The trading interface 420 is also a simplified order ticket that allows the stored algorithm to be selected as the order type by the selection interface 415.
When an order is started from trading interface 410 or 420 and a saved algorithm is selected as the order type, the order is managed according to the selected algorithm. If the selected algorithm is configured to retrieve parameters (such as order ticket price or quantity) from the trading interface, the values specified in trading interface 410 or 420 are provided to the running algorithm.
As shown in Figure 4B-Figure 4C, after the algorithm order type is selected using selection interface 415, trading interface 430 (order ticket style trading interface similar to trading interface 410 discussed above) and trading. Interface 440 (Market Depth Ladder or Axis Style Trading Interface) is shown. In this case, the algorithm chosen is similar to that shown in Figure 2I. The trading interface 440 may include a value axis that includes values that correspond to or are based on the price level of the tradable object. The value may be, for example, the price of a tradable object (such as on the price axis). Along the price axis, information related to tradable objects, such as quantities available at the price level corresponding to the value in the price axis, may also be displayed. The variables of the algorithm are shown in variable areas 435 and 445, respectively, and may be modified before the order is placed. Variable area 435 is embedded within trading interface 430 as part of the same window. The variable area 445 is incorporated into the trading interface 440 as a separate window. The variables in variable areas 435 and 445 default to the values specified in the default value column 272 of variable area 206, as shown in Figure 2I. Once modified, the initiated order will be accepted according to the algorithm selected by the modified variable value.
As shown in FIG. 4D, the trading interface 450 is an order book showing the orders accepted in the market. Here, orders 451 are selected according to an algorithm (also similar to that shown in Figure 2I). The variables of the algorithm are shown in variable areas 455 (similar to variable areas 435 and 445) and may be modified. When changed (and this change is applied), the algorithm continues to run according to the changed variable values. Variable changes take effect without pausing or stopping the algorithm.
In certain embodiments, the trading interface 450 allows the user to manually modify the orders managed by the algorithm. For example, the user may change the price or quantity of the order or delete the order. In contrast, the algorithm for managing orders may, for example, change the order price, change the order quantity, do nothing, or simply manually to use according to the algorithm definition. It only has new information or thresholds based on the modification and does not have to take any new action.
In certain embodiments, the trading interface 450 may include orders that are not controlled by the algorithm (eg, manually entered orders). This unmanaged order may be selected and an algorithm may be applied to it. For example, the user may select an unmanaged order and be presented with a list of available algorithms to apply to the selected unmanaged order using actions such as menu items or keyboard commands. The list of available algorithms may include, for example, a stored algorithm containing an order block. Once applied to the selected unmanaged order, the selected algorithm may then manage the order according to the algorithm. As another example, the user selects an unmanaged "valid until cancellation" ("GTC") order, and places the selected algorithm in this order so that the algorithm can manage the order over future trading sessions. May be applied to.
As shown in FIG. 4E, the trading interface 460 is a market depth ladder or axis style trading interface similar to the trading interface 440 discussed above. It is shown that several orders have been started and are being accepted at different price levels. Order 461 was started to be managed by the first algorithm, and order 462 was started to be managed by the second algorithm. Therefore, the trading interface 460 provides a single interface for displaying a plurality of open orders managed according to the same algorithm. In addition, the trading interface 460 also provides a single interface for displaying open orders managed according to multiple algorithms.
In certain embodiments, open orders managed according to a particular algorithm are commonly identified. For example, each open order associated with the first algorithm is graphically identified by, for example, a particular background color, foreground color, background pattern, border color, border style, shape, symbol, number, text and / or font. May be done. The open order associated with the second algorithm may then be identified using, for example, different colors, patterns, boundaries, shapes, symbols, numbers, text and / or fonts.
In certain embodiments, open orders managed according to a particular algorithm are individually identified. For example, each accepting order associated with a different instance of the same algorithm is from another accepting order associated with a different instance of that algorithm in color, pattern, border, shape, symbol, number, text and / or font. It may be distinguished by an identifier such as. Orders managed according to the first instance of the algorithm may have the number "1" in the corner of its open order indicator, while orders managed according to the second instance of the algorithm have its You may have the number "2" in the corner of the order indicator that is being accepted. The display of open orders managed by different instances of a particular algorithm may be applied in combination with the view of open orders managed by the different algorithms discussed above.
As shown in Figure 4F, trading interface 470 is an algorithm manager. The trading interface 470 may also be referred to as a cockpit or dashboard. Trading interface 470 includes a list of available algorithms 471. From Listing 471, a particular algorithm may be selected. When an algorithm is selected, a view of the selected algorithm is displayed in display area 472, and a list of running instances of the selected algorithm 473 is also displayed. As illustrated, display area 472 may indicate an algorithm definition created using a trading interface similar to the trading interface 310 discussed above. However, the display area 472 may also display a view of the algorithm defined using a trading interface similar to the trading interface 200 discussed above. List 473 of the running instances of the selected algorithm shows, for example, its start time, its position, status, profit and loss, number of orders being accepted, number of executed orders, recently placed and placed for the running instance. It may include information such as / or the instrument for which the execution was received and / or the order account information.
In addition, variable area 474 displays the variables of the selected algorithm and the values of these variables for the selected instance of the selected algorithm. The variable area 474 is similar to the variable areas 435, 445 and 455 discussed above. The variables of the selected instance of the selected algorithm may be modified. When changed (and this change is applied), the algorithm continues to run according to the changed variable values. Variable changes take effect without pausing or stopping the algorithm.
In certain embodiments, trading interfaces such as trading interfaces 200, 290, 310, 410, 420, 430, 440, 450, 460 and / or 470 are algorithmically controlled orders filled at the closing of a trading session. It is adapted so that the user can specify the action if it does not exist. For example, the trading interface may allow the user to specify that the unfilled order managed by the algorithm is canceled and the algorithm is stopped. As another example, the trading interface may allow the user to specify that unfilled orders managed by the algorithm will continue to be managed at the start of the next trading session. As another example, the trading interface allows the user to resume managing unfilled orders managed by the algorithm if they are paused at the start of the next trading session and if not paused by the user. It may be possible to specify.
The components, elements and / or functions of the trading interfaces 410, 420, 430, 440, 450, 460 and 470 discussed above can be used alone or in combination, eg, as a set of instructions in hardware, firmware and / or software. It may be implemented in the form. Certain embodiments are provided as an instruction set that resides on a computer-readable medium such as memory, a hard disk, a CD-ROM, a DVD, an EPROM, and / or a file server for execution on a general purpose computer or other processing device. You may. V. Ranking Tool
FIG. 5 shows a ranking tool 500 according to a predetermined embodiment. The ranking tool 500 may be used, for example, to rank hedging options. In futures trading, one of the most common strategies is to do "spread trading". This is because traders with market-oriented risk exposure on an instrument offset and minimize their risk variables by trading one or more similar instruments. It is a method of trying to avoid the risk by suppressing or reducing it. The two prices at the time the two positions are opened generate a combination price or a spread price. Thus, the trader may eventually attempt to execute a transaction that unwinds the open position, preferably with a spread price difference that produces a profit from the price at which the position was opened.
For some automated trading programs, hedging techniques can be implemented that automatically avoid trader risk. This hedging technique may be automated to hedge on a particular instrument, or it may be programmed to choose from multiple options for the instrument according to a pre-programmed method. However, the current system does not offer hedging transactions that are not tied to the default options for instruments.
The difficulty of opening a non-automated spread trading position, especially for market makers, is that the speed gains in technology make it extremely difficult to get the opportunity to hedge trades most efficiently. .. Due to the nature of their liquid assets that play a role in the market, market makers are often unaware that they are giving (ie, executing) liquid assets to their trading partners. .. For market makers or any traders who may suddenly acquire an open trading position, the time lag between when the first leg of the spread begins and when the trader can hedge this trade is an efficient hedging and risk. It is a serious disadvantage to management. Traders who are unable to hedge transactions quickly can lose hundreds, thousands, or even millions of dollars. Traders must not only spend time deciding which instrument is the best instrument to hedge, but also execute hedging transactions.
A given embodiment provides a ranking tool 500 that provides two significant speed advantages in the manual hedging of transactions (but not limited to) for optimally generating spread positions. The first aspect is an instrument that is constantly analyzed by a pre-programmed parameter method to determine in preference which contract is the most effective instrument for selling or buying at any particular moment. Have the user preselect the ment group. In certain embodiments, this technique can be implemented to analyze various sell / buy levels in the existing spread market with respect to the instruments the program is considering. In another embodiment, it may focus on the trader's trading inventory position to determine which hedge transaction assists the trader in minimizing the trader's overall risk. In reality, there are endless ways behind the system's execution process. Traders can use this information to save time in determining which instrument is subject to risk hedging.
In addition to the ability to automatically analyze which instrument provides the best hedging, another aspect of the Ranking Tool 500 is that it is available on the market according to the pre-programmed hedging methods described above. It is to be able to be used to effectively auto-fill a buy / sell order or order group to perform the "best" hedge or hedge group. The only potential action required of a trader is to preselect the instrument to consider, enter the desired quantity (preconfigurable), and click the sell or buy execute heading on the trading interface. Is. This automatic hedger leaves the trader with various hedged trading inventories that should be accumulated at an effective spread price consistent with the trader's preferred ranking method. The Ranking Tool 500 is beneficial to all traders who run the risk of executing transactions that can be difficult to hedge in a wide range of market environments.
The ranking tool 500 includes a selection area 510 that includes a list of tradable objects that the user can identify or select for analysis. In the example illustrated, Eurodollar futures for various monthly are listed as tradable objects. The "best" column (best buy 520 and best sell 530) displays the selected instruments in rank order, where buy 520 is based on the current sell bid and sell is based on the current buy bid. It is ranked.
The order ticket portion 540 of the ranking tool 500 allows the user to enter the quantity to buy or sell according to the ranking system. The sell and buy buttons enable the automatic execution of the desired instrument. With this system, users have a variety of options, including the choice to sell / buy only the top ranked instruments, the choice to execute all selected instruments, or the choice to loop as needed. Has 550. For example, if the trader's desired quantity is not met by the quantity available for the top instrument, the Ranking Tool 500 can place a limit order for that instrument at the initial price. A more aggressive approach is to execute any quantity available in the top instrument and move to automatic hedging of the next contract as needed. Autorun simply works to the end of the list (5th place in this example) and, if the relevant quantity is not yet met, places a limit order by trading through all the higher monthly listed. The ranking tool 500 can be looped as needed, such as when a pure market order exists, and the application will continue to the next available price, starting again at the top of the list.
The components, elements and / or functions of the Ranking Tool 500 discussed above may be implemented alone or in combination in various forms, for example as an instruction set in hardware, firmware and / or software. Certain embodiments are provided as an instruction set that resides on a computer-readable medium such as memory, a hard disk, a CD-ROM, a DVD, an EPROM, and / or a file server for execution on a general purpose computer or other processing device. You may. VI. Computing device example
FIG. 6 is a block diagram showing a computing device 600 according to a predetermined embodiment. The client device 110 may include, for example, one or more computing devices 600. The client device 301 may include, for example, one or more computing devices 600. The algorithm server 302 may include, for example, one or more computing devices 600. The gateway 120 may include, for example, one or more computing devices 600. Exchange 130 may include, for example, one or more computing devices 600. Exchange 303 may include, for example, one or more computing devices 600.
The computing device 600 includes a bus 610, a processor 620, a memory 630, a network interface 640, a display device 650, an input device 660, and an output device 670. The computing device 600 may include additional, different, or fewer components. For example, a plurality of buses, a plurality of processors, a plurality of memory devices, a plurality of network interfaces, a plurality of display devices, a plurality of input devices, a plurality of output devices, or any combination thereof may be provided. As another example, the computing device 600 may not include an output device 670 separate from the display device 650. As another example, the computing device 600 may not include the display device 650. As another example, the computing device 600 may not include the input device 660. Alternatively, for example, the computing device 600 may be controlled via network interface 640 by an external or remote input device.
Bus 610 may include communication buses, channels, networks, circuits, switches, fabrics or other mechanisms for communicating data between components within the computing device 600. Bus 610 may be communicatively coupled to and transfer data to any component of the computing device 600. For example, during the installation process of a trading application, one or more computer-readable instructions to be executed by processor 620 may be transferred from input device 660 and / or network interface 640 to memory 630. When the computing device 600 is running or preparing to run a trading application stored in memory 630, processor 620 may retrieve instructions from memory 630 via bus 610.
Processor 620 is a general purpose processor, digital signal processor, application-specific integrated circuit, field programmable gate array, analog circuit, digital circuit, program processor, a combination thereof, or any other known or future development. Processing device may be included. The processor 620 may be a single device, such as network or distributed processing related, or a combination of devices. Any processing strategy such as multi-processing, multi-tasking, parallel processing and / or remote processing may be used. Processing may be local or remote, and may be moved from one processor to another.
Processor 620 may serve to execute coded logic on one or more tangible media, such as memory 630, and / or via network device 640. As used herein, logic encoded in one or more tangible media includes instructions that can be executed by processor 620 or different processors. Logic may be stored, for example, as part of software, hardware, integrated circuits, firmware and / or microcode. The logic may be received from an external communication device, for example, via a communication network connected to the Internet. Processor 620 may execute logic to perform the functions, actions or tasks illustrated or described herein.
The memory 630 may be, for example, a tangible medium such as a computer-readable storage medium. Computer-readable storage media include random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media, and more. Various types of volatile and non-volatile storage media may be included, including, but not limited to, any combination of, or other tangible data storage devices known at this time or developed in the future. The memory 630 may include a single device or a plurality of devices. For example, memory 630 may include random access memory and hard drive storage. Memory 630 may be adjacent to or part of processor 620, programmed by it, networked with it, and / or remote from it. , The data stored in memory 630 may be retrieved and processed, for example, by processor 620.
The memory 630 may store instructions that can be executed by the processor 620. The instructions may be performed to accomplish one or more of the actions or functions described or illustrated herein.
The network interface 640 may be a one-way communication coupling or a two-way communication coupling. Thus, network interface 640 may connect one, two, or more communication networks or devices in communication. For example, bus 610 may be coupled via network interface 640 with a gateway similar to gateway 120 discussed above, so that one, some or all components of computing device 600 are accessed by the gateway. It is possible or can communicate with the gateway. As another example, network interface 640 may couple bus 610 with other communication networks. The network interface 640 may be, for example, an Integrated Services Digital Network (ISDN) card or modem for providing data communication connections. As another example, the network interface 640 may be, for example, a local area network (LAN) card for providing a data communication connection to a compatible LAN connected to the Internet. Wireless links may also be implemented. The network interface 640 may, for example, transmit and receive electrical, electromagnetic or optical signals that carry analog or digital data streams that represent various types of information.
The display device 650 includes, for example, a visual output device, a cathode ray tube (CRT) display, an electronic display, an electronic paper, a flat panel display, a light emitting diode (LED) display, an electroluminescent display (ELD), and a plasma display.. Panel (PDP), liquid crystal display (LCD), thin film transistor display (TFT), organic light emitting diode display (OLED), surface-conduction electron emitting element display (SED), laser television, carbon nanotube, nanocrystal display, head mount .It may include displays, projectors, three-dimensional displays, transmissive display devices and / or other displays known at this time or developed in the future.
The display device 650 is adapted to display the transaction screen. The transaction screen may be similar to, for example, the transaction screen discussed above. The transaction screen may be bidirectional. The interactive trading screen may allow, for example, one or more trading actions to be performed using the trading screen. For example, an interactive trading screen may allow one or more order entry parameters to be set and / or submitted using one or more order entry actions. The display device 650 and / or the input device 660 may be used, for example, to interact with the transaction screen.
The input device 660 may include, for example, a keyboard, mouse, microphone, touch screen, trackball, keypad, joystick and / or other device for providing input. The input device 660 may be used, for example, to provide a command selection to the processor 620. For example, the input device 660 may be a mouse used to control a cursor displayed on the transaction screen. The mouse may include, for example, one or more buttons for selection and control.
The output device 670 may include, for example, a keyboard, mouse, speaker, touch screen, trackball, keypad, tactile device or system, joystick and / or other device for providing output. For example, the output device 670 may be used to output one or more signals, such as a tactile signal or an audible signal, to the user.
Although the present invention has been described with reference to certain embodiments, those skilled in the art will appreciate that various modifications can be made and substitutions with equivalents can be made without departing from the scope of the invention. Will be. Moreover, in order to adapt to a particular situation or material, the teachings of the present invention may be modified in many ways without departing from their scope. Therefore, the present invention is not limited to the specified embodiments disclosed, but is intended to include all embodiments within the scope of the claims.
44 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2009535713A | Cites | Japan |
| JP2003532940A | Cites | Japan |
| WO2007037310A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP11149369A | Cites | Japan |
| US04914568A | Cites | United States of America |
| US20060129475A1 | Cites | United States of America |
| 森脇大悟,データ処理サーバー「Sybase CEP/Sybase RAP-The Trading Edition」 大量データや複雑なシナリオに対応する高速イベント処理を実現,DB Magazine,日本,株式会社翔泳社,2009年 8月 1日,第19巻,第4号,p.186-189 | Non-patent | – |
| 新誠一,New Field ものづくりの明日のために ~非製造プロセスで広がる計装技術に学ぶ 解説 非製造プロセス計装アプリケーションに学ぶ,計装,日本,(有)工業技術社,2009年 4月 1日,第52巻,第4号,p.63-67 | Non-patent | – |
79 members in 11 offices
Priority claims18
| Document | Office | Kind | Date |
|---|---|---|---|
| 61253324 | United States of America | – | |
| 61253315 | United States of America | – | |
| 25332409 | United States of America | P | |
| 25331509 | United States of America | P | |
| 61263300 | United States of America | – | |
| 26330009 | United States of America | P | |
| 61312003 | United States of America | – | |
| 31200310 | United States of America | P | |
| 61318685 | United States of America | – | |
| 31868510 | United States of America | P | |
| 61320061 | United States of America | – | |
| 32006110 | United States of America | P | |
| 61393313 | United States of America | – | |
| 39331310 | United States of America | P | |
| 12905709 | United States of America | – | |
| 12905726 | United States of America | – | |
| 90570910 | United States of America | A | |
| 90572610 | United States of America | A |
Members79
| Document | Office | Kind | |
|---|---|---|---|
| US2011093378A1 | United States of America | A1 | |
| US2011093379A1 | United States of America | A1 | |
| CA2774398A1 | Canada | A1 | |
| CA3152686A1 | Canada | A1 | |
| CA3234139A1 | Canada | A1 | |
| WO2011049936A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2010308296A1 | Australia | A1 | |
| MX2012004691A | Mexico | A | |
| KR20120102644A | Republic of Korea | A | |
| WO2011049936A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2545514A2 | European Patent Office (EPO) | A2 | |
| CN102947853A | China | A | |
| JP2013508862A | Japan | A | |
| EP2545514A4 | European Patent Office (EPO) | A4 | |
| AU2010308296B2 | Australia | B2 | |
| AU2014200235A1 | Australia | A1 | |
| JP5485405B2 | Japan | B2 | |
| JP2014160466A | Japan | A | |
| SG10201405879QA | Singapore | A | |
| AU2014200235B2 | Australia | B2 | |
| AU2015213299A1 | Australia | A1 | |
| JP2016021242A | Japan | A | |
| JP5961198B2 | Japan | B2 | |
| BR112012009233A2 | Brazil | A2 | |
| MX344724B | Mexico | B | |
| JP6104329B2 | Japan | B2 | |
| US9652803B2 | United States of America | B2 | |
| AU2015213299B2 | Australia | B2 | |
| JP2017117473A | Japan | A | |
| US2017186087A1 | United States of America | A1 | |
| SG10201705134SA | Singapore | A | |
| AU2017214916A1 | Australia | A1 | |
| BR122013024230A2 | Brazil | A2 | |
| KR20180053774A | Republic of Korea | A | |
| KR101862801B1 | Republic of Korea | B1 | |
| US10096066B2 | United States of America | B2 | |
| KR101915257B1 | Republic of Korea | B1 | |
| KR20180121690A | Republic of Korea | A | |
| US2019012738A1 | United States of America | A1 | |
| JP2019071112A | Japan | A | |
| JP6513110B2 | Japan | B2 | |
| US10296975B2 | United States of America | B2 | |
| US2019236703A1 | United States of America | A1 | |
| BR122013024235A2 | Brazil | A2 | |
| AU2019213331A1 | Australia | A1 | |
| KR102017877B1 | Republic of Korea | B1 | |
| KR20190103488A | Republic of Korea | A | |
| KR102047374B1 | Republic of Korea | B1 | |
| US10504182B2 | United States of America | B2 | |
| US2020051169A1 | United States of America | A1 | |
| US10572942B2 | United States of America | B2 | |
| US2020160448A1 | United States of America | A1 | |
| CN111539815A | China | A | |
| JP6775615B2This record | Japan | B2 | |
| AU2019213331B2 | Australia | B2 | |
| MX2021002806A | Mexico | A | |
| US11055782B2 | United States of America | B2 | |
| US2021279801A1 | United States of America | A1 | |
| US11257156B2 | United States of America | B2 | |
| US2022138854A1 | United States of America | A1 | |
| CA2774398C | Canada | C | |
| US11449939B2 | United States of America | B2 | |
| US2022405842A1 | United States of America | A1 | |
| US11568491B2 | United States of America | B2 | |
| US2023130695A1 | United States of America | A1 | |
| US11823270B2 | United States of America | B2 | |
| US11842401B2 | United States of America | B2 | |
| US2024013304A1 | United States of America | A1 | |
| US2024054561A1 | United States of America | A1 | |
| CN111539815B | China | B | |
| CA3152686C | Canada | C | |
| CN118396741A | China | A | |
| CN118396741A | China | A | |
| US12136126B2 | United States of America | B2 | |
| US12190380B2 | United States of America | B2 | |
| US2025014103A1 | United States of America | A1 | |
| MX380460B | Mexico | B | |
| US2025095066A1 | United States of America | A1 | |
| US12548077B2 | United States of America | B2 |
11 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 6775615
- Application
- 1961
Titles2
- Japanese
- ユーザ定義のアルゴリズム電子取引
- English
- User-defined algorithm electronic trading
Classification
- CPC, 5
- G06Q40/04
- G06F9/44
- G06F3/048
- G06Q40/00
- G06F3/04847
- IPC, 1
- G06Q40 04
