EP3186769A1 - Vitesse de transaction idéale - Google Patents

Vitesse de transaction idéale

Info

Publication number
EP3186769A1
EP3186769A1 EP14898437.0A EP14898437A EP3186769A1 EP 3186769 A1 EP3186769 A1 EP 3186769A1 EP 14898437 A EP14898437 A EP 14898437A EP 3186769 A1 EP3186769 A1 EP 3186769A1
Authority
EP
European Patent Office
Prior art keywords
order
market
orders
race
participant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP14898437.0A
Other languages
German (de)
English (en)
Other versions
EP3186769A4 (fr
Inventor
Hayden Paul Melton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Refinitiv US Organization LLC
Original Assignee
Thomson Reuters Global Resources ULC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/533,543 external-priority patent/US10325317B2/en
Application filed by Thomson Reuters Global Resources ULC filed Critical Thomson Reuters Global Resources ULC
Publication of EP3186769A1 publication Critical patent/EP3186769A1/fr
Publication of EP3186769A4 publication Critical patent/EP3186769A4/fr
Ceased legal-status Critical Current

Links

Classifications

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

Definitions

  • the invention relates to a system and method for providing a Latency Floor (which is sometimes also referred to as Randomization) for an electronic trading venue.
  • a Latency Floor which is sometimes also referred to as Randomization
  • HFT high frequency or algorithmic trading
  • a Latency Floor also referred to as Randomization as described in Harris, L. What to Do about High-Frequency Trading. Financial Analysts Journal, March/April 2013, Vol. 69, No. 2: 6-9 and Szalay, E. Life in the slow lane. Automated Trader Magazine Issue 30 Q.3 2013, both of which are incorporated by reference in their entireties herein
  • Randomization as described in Harris, L. What to Do about High-Frequency Trading. Financial Analysts Journal, March/April 2013, Vol. 69, No. 2: 6-9 and Szalay, E. Life in the slow lane. Automated Trader Magazine Issue 30 Q.3 2013, both of which are incorporated by reference in their entireties herein
  • a latency floor mechanism may work by "batching" up messages received within the floor's value before those messages reach the CLOB, shuffling the list of messages in the batch to give the list a new (at least somewhat) random ordering, and then finally processing these messages against the CLOB according to their new random ordering. In this way the order in which the messages are processed against the CLOB is no longer completely determined by the temporal order in which they were received.
  • Other such mechanisms may instead work by adding a random delay between 0 and the (floor) value to each message when it is received and before it can be processed against the CLOB, thereby also causing a new, more random ordering of messages, as described in Harris, L. What to Do about High-Frequency Trading. Financial Analysts Journal, March/April 2013, Vol. 69, No. 2: 6-9..
  • the invention addressing these and other drawbacks relates to a system and method for detecting and distinguishing individual "races" that naturally occur on an electronic trading venue and pertain to price making and taking activity among market participants on that venue.
  • a race to take or equivalently “hit”, or “aggress”, or “lift” the bid, and a race to take the offer.
  • price making races each type of which may be uniquely identified by the pair of a maker order's side (buy or sell) and limit price.
  • An important property of the invention (herein “ideal latency floor”) is that in any given instance of a race all participants who choose to compete in that race, and can respond within the value of the floor, all have a substantially equal chance of winning it.
  • the ideal latency floor works by: (1) detecting the first message in a specific type of race at the time it is received by the venue, (2) starting a timer upon detection of that first message, (3) "batching" the first message together with other messages that also belong to that race type and that are received by the venue before the timer has reached a predetermined value (typically the value of the floor), (4) grouping messages in the batch by participant (or other similar entity) and in doing so creating a list of participants who were involved in the race, (5) shuffling that list of participants so as to arrive at a random ordering, and (6) using that shuffled list of participants as input to a predetermined "drain” strategy that, when the race's timer has reached its value, removes the messages from the batch for processing against the CLOB in a manner and sequence that is equitable to the participants given the race type.
  • a predetermined value typically the value of the floor
  • a plurality of races may be "active" at any given time, each of which has its own set of messages, its own batch and its own timer, and so on, and that may be processed in the steps (1) through (6) set forth above independently of the processing of those steps for other active races on that instrument.
  • the system may determine whether to implement an ideal latency floor for all types of races or a subset of types of races based on a configurable parameter. For example, using the system, a user such as a market operator may specify that only price taker races should be subject to the ideal latency floor mechanism while other types of market races such as price maker races should not. In this configuration messages in taker races would be subject to batching and delay, whereas messages that pertain to maker races would likely be processed against the CLOB "in real time", in the temporal ordering in which they were received (or in the manner the venue would ordinarily process them in the absence of a latency floor). In this manner, the user may define which ones of the market races will be subject to the ideal latency floor mechanism.
  • the system may determine which specific messages can trigger (or equivalently initiate, or be the first message in) a batching period based on configurable parameters. For example, using the system, a user such as a market operator may specify that both orders that "cross" top of book (e.g., buy orders with limit price greater than or equal to the best (lowest) prevailing ask price on the venue) trigger a batching period, as do cancel requests for orders that exist at top of book on the opposing side of the book. Or the venue operator might choose to exclude such cancels as a message type that triggers the start of a batching period for taker races, allowing only taker orders to trigger such batching. In this manner, the user may define which messages trigger which type of races in the ideal latency floor mechanism.
  • a user such as a market operator may specify that both orders that "cross" top of book (e.g., buy orders with limit price greater than or equal to the best (lowest) prevailing ask price on the venue) trigger a batching period, as do cancel requests for orders that
  • the system may determine which specific messages are eligible for inclusion in a batch after the batch has initially been created (i.e., after at least one message has been placed in the batch). For example, using the system, a user such as a market operator may specify that only after a batch has been created, but before its timer has reached its value, cancels on sell orders will be included in the batch for a taker race to buy. Alternatively, the user may specify such cancels may never appear in a taker race to buy. In this manner, the user may define which messages are included in a batch after that batch has been triggered (i.e., after it has been created but before its timer has reached the value) in the ideal latency floor mechanism.
  • the system may group messages received during the batching period by the market participant (or similar entity) that generated those messages. Within each group of orders, the system may retain the temporal ordering in which those messages in that group were received. For instance, all messages received from a first market participant during the batching period may be grouped together into a first set of messages from the first market participant in the temporal order in which they were received. Likewise, all messages received from a second market participant during the batching period may be grouped together into a second set of messages from the second market participant in the temporal order in which they were received, and so on.
  • the system may create a list of market participants associated with the orders and shuffle the list of market participants such that in the resulting shuffled list of market participants, each market participant will have an equal probability of appearing at each position in the shuffled list.
  • the system may then use the ordering of the shuffled list of market participants and the ordering of their group of messages to begin to "drain" messages for processing against the CLOB, as described below. In this manner, a given market participant may not benefit by submitting multiple messages.
  • the system may employ multiple, distinct strategies to drain messages from the batch for processing against the CLOB.
  • the shuffled list of participants is repeatedly iterated over removing a single message for each participant for processing against the CLOB before moving onto the next participant with messages remaining in the batch.
  • the list of participants in the batch may be iterated over once, and all a participant's messages are removed from the batch for processing against the CLOB before moving onto the next participant.
  • the orders appearing in the batch are subject to being split into smaller "child" orders where the sum of the quantities of the child orders is equal to the total quantity of their "parent" order in the batch, and the child orders (not the parent order) are processed against the CLOB.
  • a small amount of the total quantity across all orders submitted by each participant may be processed against the CLOB in a round-robin fashion thereby eliminating the advantage a participant might obtain in other draining strategies by submitting either multiple small orders for a certain quantity, or a single large order for that same quantity.
  • FIG. 1 illustrates a system of providing an ideal latency floor mechanism, according to an implementation of the invention.
  • FIG. 2 depicts an exemplary diagram for a process of providing an ideal latency floor mechanism, according to an implementation of the invention
  • FIG. 3 depicts a process flow diagram for a process of providing an ideal latency floor mechanism, according to an implementation of the invention.
  • FIG. 4 depicts an exemplary diagram that illustrates various states of a delay mechanism, such as an ideal latency floor mechanism, according to an implementation of the invention.
  • FIG. 1 illustrates a system 100 for providing an ideal latency floor mechanism, according to an implementation of the invention.
  • System 100 may facilitate a market race in which market participants who compete in the race (e.g., by choosing to make or take a price) and are able to respond within a value of a latency floor are added to a batch in which each market participant has an equal probability of winning the market race, according to an implementation of the invention.
  • market race and “race” may be used interchangeably throughout.
  • market participant and “participant” may be used interchangeably throughout.
  • central limit order book or (CLOB) as it is used throughout is not intended to be limiting, and indeed the ideal latency floor mechanism may equally apply to other such structures implemented by a venue (e.g., structures used for the purpose of matching buy orders with sell orders, for providing a view of supply and demand for an instrument traded on that venue, and so on).
  • System 100 may include a computer system 104, one or more databases 132, one or more market participants 142, an electronic order book 144, and/or other components.
  • computer system 104 may include one or more computing devices 110.
  • Each computing device 110 may include one or more processors 112, one or more storage devices 114, and/or other components.
  • Processor(s) 112 may be programmed by one or more computer program instructions, which may be stored in storage device(s) 114.
  • the one or more computer program instructions may include, without limitation, ideal latency floor application 120.
  • Ideal latency floor application 120 may execute an ideal latency floor mechanism in which market participants 142 who compete in the race (e.g., by choosing to make or take a price) and are able to respond within a value of a latency floor are added to a batch in which each market participant has an equal probability of winning the market race.
  • an ideal latency floor mechanism will be described as performing an operation, when, in fact ideal latency floor application 120 programs one or more processor(s) 112 (and therefore computer system 104) to perform the operation.
  • the ideal latency floor mechanism may sit between a socket that receives messages off a computer network, and the CLOB 144 against which those messages are ultimately processed. Before a message is processed against the CLOB 144, and after it has been pulled off the socket, it may be processed by the ideal latency floor mechanism. Market participants 142 may see only the state of CLOB 144 in market data updates, not the messages contained in any batches in the ideal latency floor mechanism.
  • Races may generally fall into two categories: maker races and taker races.
  • An individual taker race can be uniquely identified by the side of the order, and the fact the order price "crosses" the book (i.e., would fill against the current or recent state of CLOB 144 based on price). For instance, a buy order may be said to "cross the book” if its limit price is greater than or equal to the best (lowest priced) prevailing sell order (offer) in the CLOB.
  • An individual maker race can be uniquely identified by the pair of side of the order, and limit price of the order.
  • Table 1 illustrates non-limiting examples of race types and how an ideal latency floor mechanism may handle the race types. The following table is included solely to illustrate aspects of the disclosure.
  • Table 2 illustrates non-limiting examples of dimensions, configurable parameters, and brief description of whether a given race type will be subject to the ideal latency floor mechanism described herein.
  • the ideal latency floor mechanism may configurable along the following dimensions, on a per instrument basis, as illustrated in Table 2 below. The following table is included solely to illustrate aspects of the disclosure.
  • cancel messages get included in the batch of messages collected for a taker race (specifically, cancels on bid orders go into the sell taker race batch; cancels on offer orders go into the buy taker race batch).
  • cancel messages for orders at the top of book a/50 trigger the batching period (so either an order that crosses top of book or a cancel at top of book triggers the batching period, whichever is received first).
  • Floor_Lower and FloorJJpper must be both be greater than zero.
  • Floor_Upper must be greater than or equal to
  • Floor_Lower Unit of parameters is milliseconds.
  • Taker_At_Once only has meaning if Taker_Races is true
  • Maker_At_Once is true then for maker races an entire participant's orders in a batch will be drained before moving onto the next participant's orders. Same for
  • Maker_At_Once is false then for maker races then one order will be removed from each participant's order at a time, in a round robin fashion, until all orders are drained from all participants. Same for
  • the ideal latency floor mechanism may operate on various types of market races (such as those described in Table 1) based on various configurable parameters (such as those described in Table 2).
  • the ideal latency floor mechanism may detect the first order in a market race and create a "batch" for that specific market race.
  • the ideal latency floor mechanism may start a timer that when expired or otherwise reaches a certain value, indicates an end of the batch.
  • the additional orders are placed in the batch.
  • the batches are shuffled and the ordering resulting from the shuffling is the order in which the orders are processed against CLOB 144.
  • Price p o.getPriceQ; //the limit price of the order
  • Orders os M.getOrPutEmptyListlfKeyAbsent([s,p]);
  • Lines 1-3 are as described in the code, but to elaborate further: the queue Q of line 1 is continually replenished by orders submitted by market participants on a given instrument.
  • Line 2 indicates that the orders are placed at the end of the queue, so the ordering of that queue reflects the temporal ordering in which orders are received.
  • Line 3 defines the CLOB C for the given instrument; the CLOB generally comprises buy and sell maker orders and the orders it contains generally change each time a market participant submits a message for the instrument to which the CLOB pertains.
  • Line 4 defines a Map M which is a standard and widely-used data structure for mapping keys to values. They keys of the map uniquely identify each race type; the values of the map are the orders participating in that market race.
  • Line 5 declares F, the value of the floor, which may be an integer constant defining the length of the latency floor in some unit of time e.g., milliseconds (ms).
  • Line 6 is the "infinite" while loop that is executed while an electronic trading venue is operating (accepting orders/messages).
  • Lines 7-14 are for draining the batch of orders when the timer has tolled (e.g., expired) in the active market races.
  • Line 7 is a for-loop that iterates over all the entries E in the map.
  • An Entry is the pair of a key and value in the map.
  • Line 8 returns the value i.e. the list of orders, os, in a given race.
  • Line 9 obtains the first order o in the given race, i.e., the order that caused the timer to start, without removing it from the list os.
  • Line 10 checks to see if the timer has tolled for that market race by comparing the timestamp of when the first order was received (o.getTimestampO) to the current wall clock time (current_time()) as determined by a computer's clock or other time source. If the current time is after the timestamp of the order plus the value of the floor F, then the timer has indeed tolled and the orders should be shuffled and processed against CLOB. Though the precise implementation of the shuffling of the list of orders os is not shown in the pseudo-code, nor is the processing of orders against the CLOB, C, the body of the method on line 11, shuffleAndProcess((7) would perform such shuffling and processing. The specific manner in which the shuffleAndProcess((7) method operates may be implemented as described in the section entitled "Shuffling the batch and processing orders from the shuffled batch" below.
  • Lines 15-26 detects the start of a given type of market race, and if such a market race has already begun adds orders to that market race's list or batch of orders.
  • Line 15 is a for-loop that ensures that all orders that have been received since the last iteration of the outer while-loop are processed (drained).
  • Line 16 removes the first order currently in Q.
  • Lines 19-23 handle races to "aggress” or "take” liquidity out of the market.
  • the methods on C getBestBidPriceQ and getBestAskPriceQ in this line range return the price of the highest priced buy order that exists in the CLOB and the price of the lowest priced ask order that exists in the book at the instant these methods are called.
  • the limit prices of these orders are as stored in p are instead adjusted to two special values +infinity and -infinity, respectively. This adjustment is to ensure the key is the same for all orders racing to aggress the ask book, and separately for all orders racing to aggress the bid book. At most there will be one buy taker race and one sell taker race active.
  • Line 25 adds the order o to the end of the list os.
  • Line 27 closes the outer while-loop.
  • the keys in M above may uniquely identify each race type.
  • a market operator may focus on establishing an ideal latency floor for certain types of races, such as races to take prices only.
  • the map M may only contain at most two keys at once (orders racing to aggress the bid, and orders racing to aggress the offer); all other orders may be processed against the CLOB in real-time or in the manner the venue would operate in the absence of an ideal latency floor. This may all be achieved by the small change in the code section 15-26, shown below.
  • Price p o.getPriceQ; //the limit price of the order
  • Orders os M.getOrPutEmptyListlfKeyAbsent([s,p]);
  • the manner in which the ideal latency floor mechanism may shuffle the "batch" of orders in a given race is as follows.
  • the ideal latency floor mechanism may group the orders by market participant 142 (e.g., based on the market participant who submitted the orders).
  • the temporal ordering in which each market participant's orders are received may be retained.
  • the ideal latency floor mechanism may generate a list of market participants that are associated with orders in the batch.
  • the ideal latency floor mechanism may then shuffle the list of market participants in the batch such that each market participant has an equal chance of appearing at each position in the list of market participants.
  • the orders are then drained from the batch for processing against CLOB 144 by either repeatedly iterating over the list of participants removing one order from one participant at a time; or by iterating over the entire list of participants only once and removing (and processing against the CLOB) all messages from each participant before moving onto the next.
  • the system may randomly select a winning market participant from among the batched market participants and fill its first order (e.g., the first order received from the winning market participant) to the extent possible. If more orders are available to be filled, the system may randomly select a next market participant from among the batched market participants (e.g., the second one to be selected), and fill its first order (e.g., the first order received from the next market participant) to the extent possible, and so on. Once the last market participant has been selected, the system may repeat the process for the second orders of each market participant, and so on, until all orders have been filled or no more orders are available to be filled. Of course, random selections of market participants may be made individually or based on a randomly assigned ordering of the market participants.
  • Line 1 is the Map of market participants 142 to their orders (messages) that were subject to that batch (race).
  • Line 2 makes a copy of the participants which are the keys in the Map.
  • Line 3 shuffles the (ordered) list of participants, in a way such that every participant has a substantially equal chance of appearing at each position in the list.
  • Line 4 is the variable that will hold the count of remaining orders; each iteration of the do-while loop beginning on line 5.
  • Line 6 sets the number of remaining orders to zero
  • the for-loop beginning on Line 7 causes the round-robin draining operation to iterate over the list of participants, removing one order (or equivalently message) from each participant's list of orders at each iteration. As each order is removed it is processed against the CLOB per line 11. The number of orders remaining (i.e., that have not yet been processed) in this participant's list of orders is obtained and increments the total number of remaining orders in line 12.
  • the termination condition for the do-while loop is for no orders to be remaining (i.e., for all orders to have been processed against the CLOB).
  • a non-limiting example is provided by way of illustration and not limitation. If the batch contains orders al, a2, and a3 from participant A, and order bl from participant B, and orders cl and c2 from participant C, then the Map can be represented as follows, where "->" indicates a mapping from key to value, and ";” delimits pairs of keys and values, and where " ⁇ " and " ⁇ ”demarcate the beginning and end of the map's contents, respectively:
  • the system may randomly select a winning market participant from among the batched market participants and fill all of its orders to the extent possible. If more orders are available to be filled, the system may randomly select a next market participant from among the batched market participants (e.g., the second one to be selected), and fill all of its orders to the extent possible, and so on. Of course, random selections of market participants may be made individually or based on a randomly assigned ordering of the market participants.
  • Line 1 is the Map of market participants 142 to their orders (messages) that were subject to that batch (race).
  • Line 2 makes a copy of the market participants 142 which are the keys in the Map m.
  • Line 3 shuffles the (ordered) list of market participants 142, in a way such that every market participant 142 has a substantially equal chance of appearing at each position in the list.
  • Line 4 begins a for-loop that iterates over market participants 142 based on the order they were shuffled into.
  • Line 6 processes the market participant's order against the CLOB.
  • Line 8 clears the list of orders associated with a market participant (if for no other reason than to be consistent with the previous round robin draining example where the orders are actually removed from the list after they have been processed).
  • Map m [078] A non-limiting example is provided by way of illustration and not limitation. If the batch contains orders al, a2, and a3 from participant A, and order bl from participant B, and orders cl and c2 from participant C then the Map m can be represented as follows:
  • the system may process a predetermined amount of quantity from each participant's orders at a time, repeatedly iterating over participants until the quantity remaining to be processed against the CLOB is zero for them all. For example, if the predetermined amount of quantity is 1M of base currency on a given foreign exchange instrument (this may correspond to the minimum trade size on the venue and the minimum increment in which order size can change), then 1M of the first participant's first order will be processed against the CLOB, then 1M of the second participant's first order will be processed against the CLOB, and so on until there is no quantity remaining on any participant's orders.
  • the predetermined amount of quantity is 1M of base currency on a given foreign exchange instrument (this may correspond to the minimum trade size on the venue and the minimum increment in which order size can change)
  • Line 2 makes a copy of the market participants which are the keys in the Map m.
  • Line 3 shuffles the (ordered) list of participants, in a way such that every market participant has a substantially equal chance of appearing at each position in the list.
  • Line 4 is the variable that will hold the count of remaining orders; each iteration of the do-while loop beginning on line 5.
  • Line 5 defines the split size for the orders. Its value may sensibly be to the minimum order size on the trading venue, or some other "small" value. For the purposes of this example it is assumed to be 1, and all orders are assumed to have quantity strictly greater than 0, with quantity a whole number (not fractional number).
  • Lines 6-20 are structurally similar to the round-robin draining operation pseudo-code example in that the for-loop beginning on Line 8 causes the equitable quantity race draining operation to repeatedly iterate over the list of participants until each participant's list of orders is reduced to size zero.
  • the equitable quantity race draining operation instead removes it, decrement its quantity by the split size and create a "child" order with quantity equal to the split size, and all other properties of the child order are to be inherited from its "parent".
  • the decrementing of the parent order quantity which ensures the sum of the sizes (quantities) of the child orders are equal to the parent's order size, is performed on line 12.
  • the above nine lines of pseudo-code is a partial implementation of the Order class used in the example of the equitable maker race draining operation described above.
  • the qty field of Line 2 stores the order's quantity (size).
  • the (optional) parent field of Line 3 stores the parent order.
  • the parent order is the order that was subject to the splitting in this draining mechanism.
  • the constructor beginning on line 4 assigns values to the fields.
  • Line 8 is a comment indicating that a full implementation of an Order class would likely contain additional fields to store information such as limit price, time-in-force and so on.
  • Cancel-Replace requests are widely used by market participants on many electronic trading venues.
  • a replace message in one atomic operation, cancels an existing order in the CLOB and contingent on the success of that cancellation it creates a new order at a new requested price level and new requested quantity.
  • the old order and new order in a replace request will have the same side (e.g., a buy order cannot be replaced with a sell order).
  • the replace message will be rejected (i.e. no new order created) if the old order was filled while the replace message was "in flight" between the market participant who sent it, and the trading venue that received it.
  • the ideal latency floor mechanism may handle such replace messages in various ways.
  • the ideal latency floor mechanism may handle a replace message is by splitting the replace message into two parts inside the mechanism (a cancel message, and a new order message) and handle each of those separately in the mechanism. In doing so, the ideal latency floor mechanism must ensure that if the cancel fails, the new order does not get submitted into the CLOB. Furthermore, the ideal latency floor mechanism must ensure that the cancel message "extracted" from the replace is always processed against the CLOB before the new order that was also "extracted” from it. Additionally, the ideal latency floor mechanism must ensure that the open quantity of the new order reflects any fills that occurred on the old order (i.e., the existing order subject to the replace) up to the point in time it was canceled.
  • One advantage of splitting the replace message inside the ideal latency floor mechanism is that the mechanism may have configuration parameters describing how to handle cancels and new orders with respect to batches (races) per Table 2, but no explicit configuration parameters on how to handle replaces per-se. Those existing parameters would apply to the new order and the cancel extracted from the replace, but with the caveat that the cancel must be processed before the new order. Thus, the ideal latency floor mechanism would have to ensure that the cancel is processed before the new order (and may require some degree of communication between two batch/race instances). Also, the interface through which the ideal latency floor mechanism communicates with the CLOB would have to likewise ensure that it operates in a manner that the cancel is processed before the new order. [097] To support splitting of replaces into cancels and new orders a method may be included on the interface to the CLOB used by the ideal latency floor mechanism to process a cancel message as follows:
  • an Order object is returned from the CLOB when a cancel message is processed by it. If the open quantity on the returned order is zero, or the order object itself is null, then that may indicate the new order extracted from the replace should not be sent into CLOB. Furthermore, since the quantities referred to in a FIX protocol replace message typically pertain to the order's "original quantity" (and not its "open quantity"), if the sum of the order's "open quantity” and “cumulative quantity" is less than the new "original quantity" as specified in the replace message, that should either cause the replace to be rejected, or the original order to be canceled without sending of a new order. What happens in that situation depends on how the specific venue handles that particular situation (some venues may reject the replace outright, and some simply cancel the original order without allowing the new one to be entered).
  • Another advantage of splitting the "replace" message into a cancel and new order is that the cancel will not be delayed if the configuration parameters of the ideal latency floor are set to process cancels in real-time i.e., not to include them in batches at all. Market makers generally prefer to be able to cancel their bids and offers in the CLOB without delay.
  • the ideal latency floor mechanism may handle the replace message "natively" without splitting up the replace message.
  • the replace message may be placed into a batch/race (whether that batch is already active, or new meaning the replace is the first message in it) that has the longest (temporal) delay.
  • the replace message may be placed into a batch/race (whether that batch is already active, or new meaning the replace is the first message in it) that has the longest (temporal) delay.
  • the replace message may be placed into a batch/race (whether that batch is already active, or new meaning the replace is the first message in it) that has the longest (temporal) delay.
  • the replace message may be placed into a batch/race (whether that batch is already active, or new meaning the replace is the first message in it) that has the longest (temporal) delay.
  • the replace message may be placed into a batch/race (whether that batch is already active, or new meaning the replace is the first message in it) that has the longest (temporal) delay.
  • the replace message may be placed into the batch
  • handling the replace message may still at least in part be dictated by the configuration parameters of the ideal latency floor mechanism. For example, if the mechanism is enabled for taker races only (and not maker races) and the new limit price of the order as specified in the replace crosses the book then it will go in the buy or sell taker batch. The cancelation of the older order will not occur until that taker batch is processed against the CLOB, meaning regardless of the configuration on the mechanism for cancels, the cancel portion of the replace will be delayed. If however, the limit price as specified in the replace does not cross the book then entire replace operation may happen in real-time.
  • the replace should go in the maker batch for the side and price level.
  • the replace may go in the longer (one which will expire further into the future) of the two batches: either the maker batch, or the taker batch.
  • Data may be collected from the ideal latency floor mechanism to ensure it is operating correctly, and has been implemented correctly.
  • the data should be stored in on a file system or database, such as database 132.
  • timestamps should be to at least microsecond precision: 1. Timestamp at which the message was received (before the message hits mechanism or CLOB), 2. I nteger reflecting total ordering in which messages we received (before the message hits mechanism or CLOB), 3. Timestamp at which the message was processed against CLOB, 4. I nteger reflecting total ordering in which message was processed against CLOB, 5. If message was subject to a batch a unique id that ca n associate all messages in that batch together, and uniquely identify the batch itself, 6.
  • Ideal latency floor application 120 may itself include different sets of instructions that each program the processor(s) 112 (and therefore computer system 104).
  • ideal latency floor application 120 may include an order reception engine 122, a trigger detection engine 124, a batching engine 126, a grouping engine 128, a randomization engine 130, an order processing engine 132, and/or other instructions that program computer system 104.
  • the various instructions will be described as performing an operation, when, in fact, the various instructions program computer system 104 to perform the operation.
  • ideal latency floor application 120 may provide an equal probability of winning the market race to those market participants which sent orders to the system within a batching period triggered by a predetermined criteria or an event (such as a first order being received).
  • ideal latency floor application 120 may receive one or more orders for a financial instrument from one or more market participants. Ideal latency floor application 120 may batch the orders received from market participants for a batching period in response to a trigger event. For example, the ideal latency floor application 120 may batch orders for a given instrument when: (i) the orders (or messages) trigger the race type and (ii) the order was entered within the batching period and is appropriate for that race type. In an implementation, ideal latency floor application 120 may sort the batched orders by the market participant and provide a resulting list of market participants corresponding to the orders sent during the batching period. [0109] In an implementation, ideal latency floor application 120 may randomly shuffle the resulting list of market participants to generate a processing order. Ideal latency floor application 120 may drain orders from the list of market participant in the randomly shuffled processing order based on the various draining operations described herein.
  • order reception engine 122 may receive one or more orders for a financial instrument from one or more market participants.
  • the market participants may be, but are not limited to, customers, market makers, broker/dealer systems, electronic communication networks (ECNs), and other exchanges.
  • ECNs electronic communication networks
  • a market maker may include any individual or firm that submits and/or maintains both bid and offer orders simultaneously for the same instrument.
  • a customer may be any entity, such as an individual, group of individuals or firm that engages in trading activity via system 100 and is not a market maker.
  • a customer may be an individual investor, a group of investors, or an institutional investor.
  • the market participants may include a process to enter orders into the ideal latency floor application 120.
  • Market participants may place various trading orders via the ideal latency floor application 120 to trade financial instruments, such as stocks or other equity securities, bonds, mutual funds, options, futures, derivatives, and currencies, for example.
  • trading orders may include bid (or buy) orders, ask or offer (or sell) orders, or both, and may be any type of order which may be managed by ideal latency floor application 120 , such as market orders, limit orders, stop loss orders, day orders, open orders, GTC ("good till cancelled") orders, "good through” orders, an "all or none” orders, or "any part” orders, for example and not by way of limitation.
  • a market participant may enter in a single order for a financial instrument.
  • a market participant may enter in multiple orders for a financial instrument.
  • order as it is used here is intended to broadly refer to all the forms of messages the electronic trading venue receives from market participants including, but not limited to, cancel requests, replace requests, new order requests and so on.
  • Orders for an instrument may be defined to compete in a market race if one or more market participants submit orders for a financial instrument which take advantage of a certain market position of that financial instrument.
  • Market race generally fall into two categories: taker races and maker races.
  • a taker race may be identified by the side of the order, and that the order price "crosses" the book (i.e. would fill against the current state of the market based price).
  • a maker race may be identified by the pair of side of the order, and limit price of the order (i.e. an order that does not match against an order of the opposing side that exists in current state of the market). It should be appreciated that the invention may have applicability beyond that of just creating an ideal latency floor mechanism for taker and maker races, as such the systems and techniques are parameterized to enable its wider-applicability.
  • a trigger detection engine 124 may detect one or more trigger events which may indicate the start of a market race. For instance, trigger detection engine 124 may detect one or more predetermined criteria or an event (such as a market data update or a first order being received for a financial instrument) which trigger a market race between market participants, as described herein.
  • trigger detection engine 124 may detect one or more predetermined criteria or an event (such as a market data update or a first order being received for a financial instrument) which trigger a market race between market participants, as described herein.
  • batching engine 126 may batch one or more orders received from the market participants which were received within a batching period from a detected trigger event.
  • the batching period may be triggered based on a trigger event and may be randomly selected within a bound (e.g., 0.9ms-l.lms).
  • batching engine 126 may group together orders for a financial instrument, for a given race type, which were received within a 1.1 milliseconds after a first order was received for that financial instrument that fulfills predetermined criteria.
  • the batching period may refer to a period of time in which market participants that respond within a value of a latency floor have an equal chance of winning a market race to make or take a price. Rather, orders may be batched together over a batching period of time, and at the end of that batching period of time, the market participants who submitted orders within the batching period are randomized to provide an order in which the market participant orders are processed. In this case, market participants which provide orders within the value of the batching period may have an equal chance of winning a race in which they choose to compete.
  • the batching period may typically, but not necessarily, be set to a small number such as 2 milliseconds (ms).
  • the value of the batching period may be set by the operator of the electronic trading system. For example, market participants that can respond to a predetermined criteria or an event (such as a market data update or a first order being received for a financial instrument), within the batching period (2ms), may have a substantially equal chance of winning that race.
  • batching engine 126 may group together one or more orders received from the market participants which were received within the batching period.
  • batching engine 126 may start or trigger the batching period in response to a trigger event. During the batching period, batching engine 126 may group together one or more orders for a financial instrument which were received within the batching period to form a batch. In an implementation, the temporal order in which the orders are received may be retained. In this case, batching engine 126 may batch the initial order for a financial instrument and all other orders for that same financial instrument that are received with a batching period after the first order was received in the temporal order the orders were received. The batching engine 126 may group together one or more orders when: (i) the orders are all price-compatible with the instrument being raced for and (ii) the order were entered within the batching period.
  • order cancellation requests may also be included in the batch if received within the batching period. Cancels may be included so that the fasters makers may not be able to cancel their orders while all taker orders are subject to the batching period.
  • orders received outside of the batching period are not grouped together and may be stored in the temporal order they are received.
  • replace orders batching engine 126 may splits the replace order into a cancel message and a new order message that are processed separately by the batching engine 126.
  • the ask price of an instrument in the market is 55 and at that price 1 million units of the instrument may be traded.
  • a new passive order is entered inside the spread which may cause a market race between market participants.
  • the new passive order may include an ask price in the market of 53 for the instrument with 1 million units of the instruments being trading at that price.
  • participant A sends an immediate or cancel buy order for 1 million units of the instrument at price 53.
  • participant B sends an immediate or cancel buy order for 1 million units of the instrument at price 54.
  • participant C sends an immediate or cancel buy order for 1 million units of the instrument at price 54.
  • participant D sends a good until cancel buy order for 1 million units of the instrument at price 53.
  • multiple instances of a batch may be attached to a single instrument. Care must be taken such that any given order goes to into only one such instance. This may be achieved by making the conditions for triggering a batching period more specific, and by making the condition under which an order is grouped in the batching period more specific. In general such conditions may be mutually exclusive between different instances of batches to avoid ambiguity about which instance of a batch an order or message goes into. For example, in the situation where there are two races occurring simultaneously or slightly overlapping in time: in particular a race to aggress an offer and a separate race to aggress a bid both on a single instrument, there may be two instances of a batch.
  • the condition to trigger the batching period for the ask-aggressor race may be: buy orders that cross the book.
  • the condition for orders to be grouped in the batch when it is in the batching period would be buy orders that cross the book and optionally cancel requests for sell orders.
  • the sides of the orders and cancel requests may be inverted when compared to the ask-aggressor instance. In this way, separate races that interleave in time may continue to have the property that all participants in those races may have an equal chance of winning them.
  • the batching engine 126 may also be configured to include additional instances of the batching period per instrument that processes maker orders of different sides (i.e. orders that are inserted into the bid or ask book) to handle maker-races on an instrument.
  • grouping engine 128 may sort the orders received within the batching period by market participant. For instance, grouping engine 128 may sort the received orders by market participant and bucket the orders by market participant. As an example, grouping engine 128 may place orders submitted by a market participant into a bucket associated with the market participant. Thus, each order received with the batching period may be associated and grouped by market participant.
  • grouping engine 128 may generate a resulting list of market participants that submitted orders within the batching period.
  • the resulting list of market participants may include the market participants and their respective orders which were submitted within the batching period.
  • each market participant's orders may be stored in the temporal order in which the market participant submitted that order.
  • batching engine 126 may provide a list of buckets associated with each participant (A- D) which include orders for each market participant that were received during the batching period. Each bucket may be filled with the respective orders for that particular market participant. The ordering of orders within each bucket may remain the temporal order in which the orders were received.
  • randomization engine 130 may randomly shuffle the resulting list of market participants to generate a processing order for the market participants. For instance, the randomization engine 130 will generate a random processing order for market participants whom submitted orders within the batching period. The processing order may be utilized to determine the order in which market participants' orders received within the batching period are processed. For example, randomization engine 130 may shuffle the resulting list of buckets such that statistically every participant (or equivalently bucket) has a substantially equal chance of being placed in each position in the processing order. The buckets may then generate a list of resulting bucket which may reflect a random ordering for processing.
  • a market participant having multiple credit codes, or multiple users, or submitting multiple orders may bestow no advantage to a participant.
  • the market participants are randomization such that each market participant has an equal chance of winning the market race. For instance, in a market race in which four market participants are racing, each market participant has a 25% chance of winning the market race no matter how many orders each marker participant submitted.
  • order processing engine 132 may process the orders according to the processing order of market participants.
  • order processing engine 132 may process the orders from market participants according to the random processing order generated by the randomization engine.
  • the specific manner in which the processing occurs may be parameterized.
  • orders may be processed in the temporal ordering that participant's orders were received from each participant before moving onto the next participant's in the processing order.
  • Maker race orders may be processed differently, for instance, in a round- robin fashion such that the first order from the first participant is processed, then the first order from the second participant is processed, then the first from the third participant is processed, eventually returning to the second order of the first participant if it exists, and so on until all of the orders are processed or the quantity of financial instruments is exhausted.
  • each participant order is processed it is matched/processed against the CLOB per a matching process (price compatibility checking, credit checking, TIF checking, MQ.L checking, etc.
  • processed against the CLOB generally means either inserted into the CLOB as a maker order, or matched against an order already in the CLOB as a taker order, or modifying an existing maker order's price or quantity, or canceling that existing maker order thereby removing it from the CLOB.
  • "maker orders” add or provide liquidity to the CLOB; taker orders consume liquidity from the CLOB.
  • order processing engine 132 may divide the quantity of a financial instrument among market participants. In this case, if the quantity raced for is 5M, then 1M (or the minimum trade size on the venue) may be attempted to be matched against the orders by the first market participant on the processing order, then the next 1M by the second market participant, and the next 1M by the third market participant and so on. If there is more quantity after processing the market participants a first time, the orders from the market participants are processed in order again in the same manner. For example, each "slice" of the maker quantity is matched against the list of orders from the market participants until one is found that it can match with, in temporal order. If one is not found then the quantity is tried against the orders for the next participant.
  • the distribution of maker quantity among market participants concludes when all the maker quantity is exhausted (matched) or when no more can be matched against the market participant orders because of credit incompatibility.
  • this implementation divides quantity raced for more equitably among the market participants. Since there is likely no correlation between race winner and quantity raced for in practice, over a long time horizon winning an equal number of races will also equate to winning an equal amount of quantity raced-for.
  • order processing engine 132 may process orders received outside the batching period in a temporal order. For example, order processing engine 132 may process orders received outside the batching period in the order they are received. It should be appreciated that the order processing engine 132 may not process the orders received outside the batching period until those orders within the batch are processed.
  • ideal latency floor application 120 may be executed on a server device.
  • computing device 110 as illustrated may include a server device that obtains a user request from a user device operated by the user.
  • the server device may perform the functionality of the ideal latency floor application 120.
  • computer system 104 may include a plurality of individual components (e.g., computer devices) each programmed with at least some of the functions described herein. I n this manner, some components of computer system 104 may perform some functions while other components may perform other functions, as would be appreciated.
  • the one or more processors 112 may each include one or more physical processors that are programmed by computer program instructions. The various instructions described herein are exemplary only. Other configurations and numbers of instructions may be used, so long as the processor(s) 112 are programmed to perform the functions described herein.
  • processor(s) 112 includes multiple processing units, one or more instructions may be executed remotely from the other instructions.
  • processor(s) 112 may be programmed by one or more additional instructions that may perform some or all of the functionality attributed herein to one of the instructions.
  • the various instructions described herein may be stored in a storage device 114, which may comprise random access memory (RAM), read only memory (ROM), and/or other memory.
  • the storage device may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor 112 as well as data that may be manipulated by processor 112.
  • the storage device may comprise floppy disks, hard disks, optical disks, tapes, or other storage media for storing computer-executable instructions and/or data.
  • a network may include any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network.
  • a network may include any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network.
  • a PAN Personal Area Network
  • LAN Local Area Network
  • WAN Wide Area Network
  • SAN Storage Area Network
  • MAN Metropolitan Area Network
  • wireless network a wireless
  • the various databases 160 described herein may be, include, or interface to, for example, an OracleTM relational database sold commercially by Oracle Corporation.
  • Other databases such as InformixTM, DB2 (Database 2) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SOL (Structured Ouery Language), a SAN (storage area network), Microsoft AccessTM or others may also be used, incorporated, or accessed.
  • the database may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations.
  • the database may store a plurality of types of data and/or files and associated data or file descriptions, administrative information, or any other data.
  • FIG. 2 depicts an exemplary diagram 200 for a process of providing an ideal latency floor mechanism, according to an implementation of the invention.
  • the various processing operations and/or data flows depicted in FIG. 2 are described in greater detail herein.
  • the described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.
  • client A's order for a particular financial instrument may be the first order in a given market race type (e.g. aggress the market, peg the top-of-book bid, top-of-book- offers, etc.).
  • the batching period i.e. two millisecond period until orders are processed
  • client A's order may be added to a batch [A].
  • the batch may be shuffled randomly and may be processed in one of these random orders: B(Process_Order(A, B, C)), B(Process_Order(A, C, B)), B(Process_Order(B, A, C)), B(Process_Order(B, C, A)), B(Process_Order(C, A, B)), or B(Process_Order(C, B, A)). Since clients A, B, and C have responded within the batching period, clients A, B, and C have an equal chance of being processed first. With continuing reference to FIG.
  • client D's order will be processed after the orders of client A, B, and C.
  • any order received outside of the batching period may be processed in the order in which they are received, or subject to an entirely new batch.
  • FIG. 3 depicts a process flow diagram 300 for a process of providing an ideal latency floor mechanism, according to an implementation of the invention.
  • the various processing operations and/or data flows depicted in FIG. 3 are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.
  • a first set of orders associated with a first market participant are received.
  • order as it is used here is intended to broadly refer to all the forms of messages the electronic trading venue receives from market participants including, but not limited to, cancel requests, replace requests, new order requests and so on.
  • the second set of orders was received within a batching period after the first set of orders was received, one of the first set of orders and the second set of orders are randomly selected in an operation 308.
  • the batching period may be triggered based on a predetermined criteria or an event (such as a market data update or a first order being received for a financial instrument) and may be randomly selected within a bound (e.g., 0.9ms-l.lms).
  • the first set of orders is processed before the second set of orders in an operation 312.
  • FIG. 4 depicts an exemplary diagram that illustrates various states of a delay mechanism, such as an ideal latency floor mechanism, according to an implementation of the invention.
  • a delay mechanism may have several states which are processed by various software modules configured in the system.
  • the state of the mechanism determines its behavior. Different instances of the mechanism operate independently of each other, and in general there may be many instances of the mechanism per instrument. For reasons described above the mechanism is parameterized on each of the following: (1) the condition that causes it to enter the DELAY state, on (2) the messages i.e., orders, cancels, replaces etc it accepts when in the DELAY state, and on (3) the manner in which the market participant buckets are drained in the DRAIN state.
  • the mechanism When instantiated on a given instrument, the mechanism is initialized to the "NORMAL" state. When the system is in the NORMAL state and an order (or message) is received that meets the given condition the mechanism enters the "DELAY" state. For aggressor races the specific condition the mechanism implements to enter the DELAY state is an order received that crosses the book i.e., an order received that is priced such that, without regard to credit, it may be matched against (aggress) the opposite side of the market.
  • the time-in-force of the order that crosses the book may be immaterial i.e., it may be an IOC or a regular GTC order; the key observation is that the order is priced such that it would aggress the (unscreened) market based off the current state of the central limit order book. (Current state may be the "true" state of the central limit order book, not what was last sent out of the venue in is market data updates)
  • the initial order and all other orders (or messages) that meet a given criteria or condition are queued up in the order they are received for a period of X milliseconds (ms) after the first order is received.
  • X will typically be a small number, and may be whole or fractional number. X may also vary randomly within some bounds (e.g., 0.9ms - 1.1ms) if it is desired to establish a "latency floor" having some variation.
  • the mechanism next enters the "RANDOMIZATION" state.
  • the criteria for messages to collect in the DELAY state is that they are orders that also cross the unscreened book, and optionally all order cancellation requests.
  • the rationale for including cancels is may be that we do not want the fastest makers to be able to cancel their orders while all taker orders are subject to a delay period; the rationale for excluding them is that cancel requests may already get priority over order messages in the venue's preexisting implementation.
  • I n the RAN DOM IZATION state the queue of orders (or messages) are bucketed by market participant, so all a participant's orders (regardless of user, credit code etc) go into single bucket for that client.
  • a (market) participant is an organization such as a bank or prime-brokerage client, and not a specific user (person) or credit code. In this way having multiple credit codes, or multiple users, or submitting multiple orders bestows no advantage to a participant.
  • the resulting list of buckets is then randomly shuffled and the result of this is the system enters the "DRAIN" state.
  • the random shuffling may be implemented such that statistically every participant (or equivalently bucket) has an equal chance of ending up in each position in the resultant list of buckets.
  • the ordering of orders (or messages) that were subject to this delay for a given participant is retained when they are put into that client's bucket.
  • the system drains the orders from the buckets in the order determined by the bucket ordering.
  • the specific manner in which the draining occurs is parameterized. For these aggressor-races all orders are drained from each participant's bucket before moving onto the next participant's in the list, in the temporal ordering that participant's orders were received.
  • this mechanism may be used elsewhere e.g., for maker races orders (message) may be drained differently, for instance, in a round-robin fashion or an equitable quantity fashion.
  • each client order is removed from the buckets, at the time each order (or ca ncel request/message in other scenarios) is removed it is matched/processed against the central limit order book per a matching process (price compatibility checking, credit checking, TI F checking, MOL checking etc). Once all buckets are drained the mechanism reverts to the NORMAL state.
  • Appendix A includes an example of instructions used to implement an ideal latency floor mechanism according to the parameters described in Ta ble 2, which is provided by way of illustration and not limitation. As would be apparent based on the disclosure herein, other sets of instructions may be used as well.
  • boolean drainAtOnce batch. isTakerRace ? takerAtOnce : makerAtOnce; //the logic for draining the batch i.e., doing the randomization //orders in a specific race type lives inside of the Batch class,
  • variable priceSide will be the //"key" that identifies a race in our activeRaces map
  • PriceSide priceSide msg.priceSideKeyO
  • priceSide. price null
  • priceSide.isBuy IpriceSide.isBuy
  • startTimeMillis msg.getReceiveTimestampO
  • processing against the CLOB means applying the message to the //CLOB by price checking the opposite side of the market for a possible match, //credit checking for a possible match, inserting the order into the book, //matching the order, removing the order from the book and so on.
  • PriceSide priceSideKeyQ ⁇ return null
  • Double getPrice() ⁇ return null; ⁇

Landscapes

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

Abstract

L'invention concerne un système et un procédé permettant de fournir une vitesse de transaction pour un site de transaction électronique dans lequel les participants au marché qui peuvent répondre à l'intérieur de la valeur de vitesse de transaction et choisir d'entrer en compétition dans une compétition spécifique pour faire ou prendre un prix peuvent chacun avoir une chance sensiblement égale de gagner cette course. Le système peut détecter et distinguer des "compétitions" individuelles qui se produisent sur un site de transaction électronique. Lors de la détection du premier ordre (ou du premier message) dans une telle compétition, le système peut créer un lot et un compteur pour cette compétition. Lorsque des ordres se rapportant à cette compétition sont reçus, ils sont ajoutés à son lot. Lorsque le compteur a atteint une valeur prédéfinie, typiquement la valeur de la vitesse de transaction, la course est déterminée comme étant finie et les ordres sont prélevés du lot en vue d'un traitement (par exemple, par rapport au livre d'ordres plafond central (CLOB) de l'instrument).
EP14898437.0A 2014-07-25 2014-12-30 Vitesse de transaction idéale Ceased EP3186769A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462029042P 2014-07-25 2014-07-25
US14/533,543 US10325317B2 (en) 2013-11-05 2014-11-05 Ideal latency floor
PCT/US2014/072796 WO2016018453A1 (fr) 2014-07-25 2014-12-30 Vitesse de transaction idéale

Publications (2)

Publication Number Publication Date
EP3186769A1 true EP3186769A1 (fr) 2017-07-05
EP3186769A4 EP3186769A4 (fr) 2018-01-10

Family

ID=55218158

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14898437.0A Ceased EP3186769A4 (fr) 2014-07-25 2014-12-30 Vitesse de transaction idéale

Country Status (7)

Country Link
EP (1) EP3186769A4 (fr)
JP (1) JP6464348B2 (fr)
CN (1) CN106688008B (fr)
AU (2) AU2014402295A1 (fr)
CA (1) CA2956079C (fr)
SG (1) SG11201700613XA (fr)
WO (1) WO2016018453A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11144993B2 (en) 2013-11-05 2021-10-12 Refinitiv Us Organization Llc Delay-free matching for deemphasizing effects of speed differentials among price-makers
US10325317B2 (en) 2013-11-05 2019-06-18 Refinitiv Us Organization Llc Ideal latency floor
US10909621B2 (en) 2013-11-05 2021-02-02 Refinitiv Us Organization Llc Systems and methods for quantifying temporal fairness on electronic trading venues
CN110691263A (zh) * 2018-07-05 2020-01-14 武汉斗鱼网络科技有限公司 同步本地与服务器时间的方法、介质、电子设备及系统
CN114788224A (zh) * 2019-12-18 2022-07-22 维萨国际服务协会 对分布式环境中已取消的请求的访问管理

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7430533B1 (en) * 2000-01-11 2008-09-30 Itg Software Solutions, Inc. Automated batch auctions in conjunction with continuous financial markets
JP2003108774A (ja) * 2001-09-28 2003-04-11 Tokyo Commodity Exchange 電子的約定締結システム及び約定締結方法
US7979339B2 (en) * 2006-04-04 2011-07-12 Bgc Partners, Inc. System and method for optimizing execution of trading orders
US7853499B2 (en) * 2007-03-29 2010-12-14 Board Of Trade Of The City Of Chicago System and method of allocating an incoming order to standing orders
US8170949B2 (en) * 2008-08-11 2012-05-01 Bgc Partners, Inc. Products and processes for order distribution
CA2750553A1 (fr) * 2009-01-23 2010-07-29 Cfph, L.L.C. Techniques de traitement reparti multi-ordinateurs visant a empecher des fuites d'informations
US20110040669A1 (en) * 2009-08-17 2011-02-17 Darren Lee Automated spread trading system
US20120054084A1 (en) * 2010-08-27 2012-03-01 Wolf Brian M Delta Neutral Futures Allocation
US11989779B2 (en) * 2012-10-04 2024-05-21 Trading Technologies International, Inc. Configurable order entry, matching, coordination, and market data intervals

Also Published As

Publication number Publication date
JP2017522683A (ja) 2017-08-10
CA2956079C (fr) 2019-07-09
JP6464348B2 (ja) 2019-02-06
AU2018220100A1 (en) 2018-09-13
CN106688008A (zh) 2017-05-17
AU2014402295A1 (en) 2017-02-02
SG11201700613XA (en) 2017-02-27
CN106688008B (zh) 2021-03-09
CA2956079A1 (fr) 2016-02-04
EP3186769A4 (fr) 2018-01-10
WO2016018453A1 (fr) 2016-02-04

Similar Documents

Publication Publication Date Title
US11798077B2 (en) Ideal latency floor
AU2018220100A1 (en) Ideal latency floor
US11295384B2 (en) Method and apparatus for order entry in an electronic trading system
Hasbrouck et al. Technology and liquidity provision: The blurring of traditional definitions
Schmidt Financial markets and trading: an introduction to market microstructure and trading strategies
Wah et al. Strategic market choice: Frequent call markets vs. continuous double auctions for fast and slow traders
JP2020074217A (ja) ダイナミックペグ注文を行うための装置およびシステム
WO2021000475A1 (fr) Procédé basé sur un graphe bipartite pour détecter des groupes suspects de transactions boursières collaboratives
CA3010843A1 (fr) Correspondance de priorite pour commandes de fabricant presentant une annulation differee
Fricke et al. The effects of a financial transaction tax in an artificial financial market
Vaananen Dark pools and high frequency trading for dummies
US20120191590A1 (en) Simplified quote sharing calculation
CN109035008A (zh) 交易信息处理方法及交易系统
Subasi Investor conferences and institutional trading in takeover targets
CN108549982A (zh) 信息推荐方法、电子设备和计算机存储介质
JP2020504370A (ja) 電子取引システムにおいて完全または部分的表示ダイナミックペグ注文を処理するシステムおよび方法
Azmi et al. Benchmarking developed property portfolio markets in Malaysian-listed property companies
Le et al. Dynamic limit order placement strategies: survival analysis with a multiple-spell duration model
Virgilio Absolute vs. relative speed in high-frequency trading
Curwen Restructuring of the TMT sector gathers pace during 2005/06
Berthélemy Sub-Saharan Africa and International Public Goods: The Weakest Link or a De-linked Region?
CN109344182A (zh) 自选股展示法
Brown et al. How much is a Dollar Worth? Tipping versus Equilibrium Coexistence on Competing Online Auction Sites!
Ning Three essays on international futures markets
Hsieh et al. The magnet effect of price limits: Evidence from transactions data

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170222

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: THOMSON REUTERS GLOBAL RESOURCES UNLIMITED COMPANY

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20171212

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 40/04 20120101AFI20171206BHEP

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: THOMSON REUTERS (GRC) INC.

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: REFINITIV US ORGANIZATION LLC

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20210201