[go: up one dir, main page]

WO2018009719A1 - Système, procédé et appareil permettant un accès impartial dans des lieux de marché - Google Patents

Système, procédé et appareil permettant un accès impartial dans des lieux de marché Download PDF

Info

Publication number
WO2018009719A1
WO2018009719A1 PCT/US2017/040980 US2017040980W WO2018009719A1 WO 2018009719 A1 WO2018009719 A1 WO 2018009719A1 US 2017040980 W US2017040980 W US 2017040980W WO 2018009719 A1 WO2018009719 A1 WO 2018009719A1
Authority
WO
WIPO (PCT)
Prior art keywords
latency
radius
participant
market
order
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
PCT/US2017/040980
Other languages
English (en)
Inventor
Kristofer SPINKA
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.)
Tradition America LLC
Original Assignee
Tradition America LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tradition America LLC filed Critical Tradition America LLC
Publication of WO2018009719A1 publication Critical patent/WO2018009719A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

  • Venue participants route held orders, including orders from retail investors, to a variety of venues for execution.
  • Venues include market makers, alternative trading systems, and registered exchanges.
  • Retail orders are defined as orders from individual investors, and held orders are orders where the executing broker/market maker is obligated to fill, display, or route the order to another venue.
  • these orders are benchmarked against the current National Best Bid and Offer (NBBO) on arrival.
  • NBBO National Best Bid and Offer
  • Figure 1 is a block diagram of an example network topology of an order routing system, according to certain embodiments.
  • Figure 2 is a block diagram of an example processing module configuration of the order routing system of Figure 1;
  • Figure 3 is a block diagram of an example network topology of a market venue
  • Figure 3 A is a block diagram of an example network topology of a market venue
  • Figure 4 is a block diagram of an example network topology of a trading floor
  • Figure 5 is a flow chart of an example latency radius calculation method according to certain embodiments of the invention.
  • Figure 6A is a flow chart of an example radius application method according to certain embodiments of the invention.
  • Figure 6B is a flow chart of an example latency radius application method according to certain embodiments of the invention.
  • Figure 6C is a flow chart of an example transmission method based on the latency radius according to certain embodiments of the invention.
  • Figure 7 is a block diagram of an example computing device.
  • Systems and methods for adapting held order flow to enhance order execution performance are configured to determine a latency radius for participants in one or more market venues as orders are processed by market venues (e.g., market makers, ATSs, or registered exchanges).
  • the latency radius may be used to create an equilibrium between market participants to remove the advantages inherent in varying latency market communications.
  • FIG. 1 is a block diagram of an example order routing system 100, including one or more processing systems (e.g., processors, computing devices, servers, virtual machines, parallel processing threads, etc.), such as an inbound server 102, order router 104, and outbound server 106, which are configured to receive inbound orders 118 submitted by customers 11, identify the appropriate market venue(s) 126 for fulfillment of each of the orders based on factors such as displayed liquidity, commissions and/or rebate structures, latency, market spread, projections on execution volume for an instrument based on the venue, best inside market on either bid or ask, and fill ratios, route the inbound orders 118 to the selected market venues 126, and update market venue statistics in real-time based on actual fill data 122 to refine the expected behaviors of the market venues 126.
  • processing systems e.g., processors, computing devices, servers, virtual machines, parallel processing threads, etc.
  • the order routing systems communicates with customer devices 116, such as end retail investors and/or retail brokers, via a customer network 114.
  • customer devices 116 such as end retail investors and/or retail brokers
  • a particular order may be submitted directly to the order routing system 100 via a customer computing device 116a or 116b, or the order may reach the order routing system 100 via one or more intermediary computing systems 116c, such as a retail brokerage computing system.
  • the customer network 114 depending upon the deployment configuration of the order routing system 100, may include the Internet, one or more intranets, local area networks (LANs), Wide Area Networks (WANs), and/or Metropolitan Area Networks (MANs).
  • LANs local area networks
  • WANs Wide Area Networks
  • MANs Metropolitan Area Networks
  • the customer devices 116 are illustrated as communicating with the customer network 114 through wireless connections, depending upon the deployment configuration, some customer devices 116 may communicate with the customer network 114 via a wired or cabled connection.
  • the order routing system 100 routes the particular order to a selected market venue 126 via a market network 124 which may include similar network components as described in relation to the customer network 114. Additionally, in some embodiments, at least a portion of the networking configuration of the customer network 114 may be shared with the market network 124.
  • the inbound server 102 receives customer inbound orders
  • the customers may place the inbound orders 118 directly to the inbound server 102 via customer computing devices such as customer devices 116a, 116b, and/or the inbound orders 118 may be submitted by one or more intermediate computing systems 116c on behalf of the customers.
  • a particular customer may place an order with the inbound server 102 through the intermediate computing system 116c via a web interface, handheld device application, or telephone interface.
  • the inbound server 102 may normalize the inbound orders 118 prior to providing the inbound orders 118 to the order router 104.
  • the inbound server 102 may convert customer-specific order formats into a common format that corresponds to a format used by the order router 104 for making trading/routing decisions.
  • the order router 104 in turn, may make trading/routing decisions, such as selecting market venues 112 for routing the inbound orders 118.
  • the outbound server 106 receives the inbound order 118 from the order router 104 and formats the inbound orders 118 for the market venues 112. Once the orders are filled by the market venues 112, the outbound server 106 may normalize actual fill data 120 (interchangeably referred to as a filled order) received from the market venues 112 and pass the actual fill data 120 to the order router 104 where real-time order statistics 128 are updated. For example, individual market venues may process orders based on a venue-specific format, so the outbound server converts the order data from the order router 104 to the venue specific format when placing the order.
  • the real time order statistics 128 may also be based in part on market data 110 reflecting order activity external to the order routing system 100 (e.g., orders placed via other order placement systems in communication with the market venues 112).
  • the order router 104 makes order routing decisions based on the real-time order statistics 128 as well as historical data 108.
  • a database server (not illustrated) includes processing logic configured to process the historical data 108.
  • a database server stores the historical data 108, which is processed by the order router 104.
  • the order router 104 may also route the actual order data 120 to the inbound server 102, which may format the fill data 120 in accordance with customer (or third party intermediary) specifications.
  • FIG. 2 is a block diagram of an example processing module configuration 200 of the order routing system 100 of Figure 1, according to certain embodiments.
  • the processing module configuration 200 provides a detailed processing flow for the routing of orders through the order routing system 100.
  • the processing module configuration 200 includes a number of discrete processing modules, such as an order management module 202, a message data storage module 208, a market data interface module 203, an order processing module 210, and an exchange interface module 206 for handling order receipt and fulfillment.
  • Each module may include one or more routers/servers or other processing logic or circuitry that executes the processes described herein.
  • the distribution of processing circuitry shown in the processing module configuration 200 is merely example and other computing systems, processing circuitry, and/or distribution of processing tasks may be used.
  • the inbound server 102 of the order routing system 100 of Figure 1 includes the order management module 202.
  • the order management module 202 may include a customer interface server 212 that receives a customer order via the network 114.
  • the customer interface server 212 may send an order acknowledgement to the customer and route the order to an order management server 214.
  • the order management server 214 may validate the order to ensure the order is in accordance with customer specifications and then transmit the order to the messaging data storage module 208.
  • the inbound server 102 includes the messaging data storage module 208, having a trading database 218 as well as a trading notification server 216.
  • the order transmitted from the order management module 202 to the messaging data storage module 208 may be posted to the trading database 218 and notify an order processing server 220 in the order processing module 210.
  • the outbound server 106 of Figure 1 includes the order processing module 201.
  • the order processing server 220 may query the trading database 218 in response to the notification to obtain the order information from the trading database 218.
  • the order processing module 201 also includes an execution platform 222.
  • the order processing server may provide the order to the execution platform 222 and the execution platform 222 may determine routing information for the order based on factors such as displayed liquidity, commissions and/or rebate structures, latency, market spread, projections on execution volume for an instrument based on the venue, best inside market on either bid or ask, and fill ratios, customer trading specifications, the historical data, and real-time order statistics.
  • the real-time order statistics are based on live market data received from the market data interface module 204 (e.g., included as part of the order router 104 of Figure 1).
  • the execution platform 222 may send the order routing information to a market trading server 224 in the exchange interface module 206.
  • the outbound server 106 of Figure 1 may include the exchange interface module 206.
  • the market trading server 224 routes the order according to the order routing information to an instance of a market interface server 226 associated with a particular destination market venue 126.
  • the market interface server 226 may route the order to the selected destination market venue 126 via the market network 124, where the order is filled.
  • the market interface server 226 receives the actual fill data (also referred to as fill details), via the market network 124 from the market venue 126 and routes the actual fill data (e.g., filled order 120) back to the market trading server 224.
  • the market trading server 224 may post the fill details to the trading database 218 of the messaging data storage module 208 and also provide the fill details to the execution platform 222 of the order processing module 210 in a normalized format.
  • the execution platform 222 may update the real-time order statistics based on the actual fill data so that future orders are based on the requested fill data from a current order.
  • the trading notification server 216 identifies the fill details posted to the trading database 218 and sends the fill details to the order management server 214 of the order management module 202.
  • the order management server 214 may provide the fill details to the customer interface server 212, and the customer interface server 212 may route the fill details to the customer via the network 114 in a predetermined format.
  • Customers who initiate orders via the order routing system 100 can specify one or more target metrics that are used by the order router 104 to make determinations regarding where orders are routed.
  • Target metrics in some examples, can include execution speed, price improvement, fill rate, and the like.
  • the order router 104 of Figure 1 can select the market venues 126 for routing received orders based at least in part on expected performance of the market venues 126 with respect to the customer's target metrics.
  • market data may be received in real-time, which is less processed and includes less analytics.
  • examples of real-time, lower latency market data include Reuters® Data Feed Direct and Bloomberg B-Pipe®.
  • REUTERS is a registered trademark of Thomson Reuters Canada Limited
  • B-PIPE is a registered trademark of Bloomberg Finance One L.P
  • latency may also be reduced by receiving feeds directly from an exchange.
  • the data is communicated in FIX® format (Financial
  • FAST Fix Adapted for Streaming
  • FAST uses compression to reduce message length, which reduces latency.
  • the system may be configured for direct market access (DMA). DMA enables direct routing a securities order to a market venue 126.
  • DMA direct market access
  • Figure 3 further illustrates a non-limiting example of the configuration of a market venue according to some embodiments of the invention.
  • the market interface server 226 may send an inbound order 118 to order consolidator 302.
  • the market interface server 226 may communicate directly with participant connectivity switch 304. From there, the inbound order 118 may be sent to order database 306, which in turn may send inbound order 118 to the matching network 310 for execution.
  • a matching engine may reside in any of participant connectivity switch 304, order database 306, or matching network switch 308, depending on desired performance characteristics. If the matching engine determines that the inbound order 118 cannot be filled by matching network 310, any of participant connectivity switch 304, order database 306, or matching network switch 308 may transmit the unfilled order to trade and quote database 312 for publication to the market venue 126.
  • the matching engine in Figure 3 is positioned at the matching network switch 308, which is why the matching network switch 308 is illustrated as communicating the unfilled inbound order 118 to the trade and quote database 312.
  • filled order 120 is sent from the matching network 310 to the matching network switch 308.
  • Matching network switch 308 may send the filled order 120 to the order database 306. After the filled order reaches the order database 306, it may be sent to participant connectivity switch 304 and then to order consolidator 302. If the market venue is not using an order consolidator 302, the participant connectivity switch 304 may send the filled order 120 to the market interface server 226.
  • the exchange interface server 314 may communicate information about inbound order 118 to market venue 126. More specifically, the exchange interface server may send inbound order 118 to specific market venues 126b ... 126n for their trade databases 316b ... 316n and quote databases 318b ... 318n for execution on an alternative venue.
  • Figure 3 A illustrates a market network configuration according to some embodiments of the invention.
  • market interface server 226 may send inbound order 118 to an order entry gateway 340 of a market venue.
  • the order entry gateway 340 may acknowledge receipt of the order to the market interface server 226.
  • the inbound order 118 may be transmitted to matching engine 342. If the matching engine 342 determines that the order is capable of being filled at that market venue, the inbound order 118 may be transmitted to the point of match 344. If the matching engine 342 determines that the inbound order 118 cannot be filled in the venue, the matching engine may transmit the inbound order 118 to market data interface 346.
  • the inbound order 118 may be transmitted to the market venue 126 for execution.
  • the filled order 120 may be transmitted from the market venue 126 to the market data interface 346.
  • the market data interface 346 may transmit the filled order to the matching engine 342, and the matching engine 342 may transmit the filled order to the order entry gateway 340 for transmission to the market interface server 226.
  • the filled order information may be transmitted to a location other than market interface server 226.
  • the filled order information may be transmitted to other market venues.
  • the market data interface 346 may communicate filled order 120 to market interface server 226, directly or via intermediaries.
  • FIG. 4 provides a more detailed explanation of the matching network 310 according to some embodiments of the invention.
  • Display book 402, printer 404, handheld device 406, booth support 408, and crowd display 410 may all send and receive information interactively.
  • the matching network may provide the point of match for the trade, for example via the display book 4.
  • Crowd display 410 may receive information from crowd display server 412, which in turn may receive information from market venue 126.
  • the crowd display server 412 may provide additional information regarding trading activity in other selected market venues 126a ... 126n.
  • the processing circuitry of order router 104 may also route orders directly to exchanges at times based on order classifications, such as whether the order is marketable or non-marketable, time of day, and the like.
  • the order router 104 may route orders to the market venues early in the day and then route orders directly to actual exchanges later in the day.
  • embodiments of the invention may select a network participant 1 ... q in step S500 to measure the latency between the network participant and the market venue.
  • S500 may occur periodically, upon random or specified intervals, upon entry of a network participant into the network, or at other times as may be desired.
  • the venue may or may not inform network participants that the venue is measuring latency and may adjust communications according to the measured latency between the venue and participants.
  • the latency is measured between the network participant and the venue.
  • the result of S502 is compared to the greatest prior measured latency of the measured latencies for each network participant 1 ... q. If the most recently measured latency is more than the greatest previously measured latency, the system may be configured to set the most recently measured latency as the latency radius in step S508. If the most recently measured latency is less than the greatest previously measured latency, the system may retain the previously measured greatest latency as the latency radius in step S506.
  • the system may overwrite the existing value in step S506 or may not, as desired. By overwriting the existing value, the system may retain additional metadata associated with the value, such as time of measurement, which may be desired for reasons such as data tracking and system efficiency, for example.
  • step S510 the system may check to see if all network participants have been queried. If they have not been queried, the system may return to method step S502 to iteratively process latency radius calculations until all network participants have been queried. Once all network participants are queried, the latency radius is output in step S512.
  • the calculation of FIG. 5 derives the latency radius as a simple maximum latency value across all venue participants, more complex techniques may be used as desired. For example, a predetermined ceiling value may be applied to limit the latency radius so that it is not completely controlled by a worst participant. Other techniques may apply consensus algorithms, such as calculating the latency radius as a mean across all participants, which may exclude outliers. Other techniques may be used as desired.
  • Avenue may have more than one latency radius.
  • the latency radius for a venue may be dynamic, with the latency radius expanding or contracting from time to time as conditions change. For example, variances in participant statistics may cause the latency radius to change.
  • the latency radius may also change based on the time of day or market factors such as spreads.
  • the latency radius for different types of events may differ.
  • a latency radius for order books (quotes) may be different from the latency radius for executions or order entries.
  • the multiple latency radiuses may be independent, but in some cases the several latency radiuses may have constraints or dependencies between them.
  • the calculations may be performed multiple times and statistical grooming techniques used to derive the final latency radius value. For example, above and below thresholds may be used to remove outlier values.
  • moving averages may be employed and the latency radius may be constrained to be within a tolerance above or below the moving average.
  • the latency radius may be constrained to be within a predetermined number of standard deviations from a previous sample vector regression of latency radius values. Any statistical technique may be used to develop the latency radius from multiple measurements.
  • latency can be measured as a roundtrip calculation or may be measured in a single direction.
  • the connection time method may be used to measure latency using TCP protocol.
  • the connection time metric corresponds to the time interval between when a SYN packet is sent to the network participant.
  • the network participant returns a SYNACK packet, and the system sends back a SYN packet to the network participant.
  • the SYN, SYNACK, and SYN packets are given priority handling.
  • the time interval between the SYN and the ACK packet may be used as the latency measurement.
  • connection setup times may vary from connection to connection, in some embodiments the latency radius would be calculated as an average over several connection time measurements or using some other statistical approach to achieve a constant value. However, connection time measurements potentially could be manipulated by venue participants.
  • latency may be measured as the time interval between a packet containing a payload and its corresponding acknowledgement packet. This may be considered a good indicator of round trip network latency. However, some side effects, such as delayed acknowledgements or overloaded systems may cause this latency measurement to be less accurate than the connection time method.
  • Embodiments of the invention may also use other methods to measure latency. For example, in market venues using the UDP/IP multicast for market data dissemination, measurement of a network participant's latency may be inferred from a measurable control channel. For example, an agent of the venue may perform an inspection, a token system may distribute decryption keys that must be used to decrypt what is arriving over the broadcast channel, may require periodic roundtrip acknowledgements from network participants, may use equipment under the control of the market venue, or may use technology such as low earth orbit (LEO) satellites.
  • LEO low earth orbit
  • This calculated latency radius is therefore different from static latency buffers that apply a fixed latency for all data transfers for all venue participants.
  • the technique differs from techniques that may use random latency buffers. The techniques described above produce a deterministic latency radius that attempts to level the connectivity imbalance that produces different latencies for different venue participants.
  • the latency calculations or measurements may be performed at multiple logical layers of the connectivity stack.
  • the measurements may measure physical media by using optical time-domain reflectometer (OTDR) techniques, link- level measurements, and protocol -level measurements.
  • OTDR optical time-domain reflectometer
  • a latency radius may be responsive to not only the connectivity path, but the usage of the path by the participant. For example, in the event that a participant is exhibiting quote stuffing like behavior, this may be used by the system to increase his wait times as he is negatively impacting the latency of others. So transmission path and inter-order arrival spacing are both usable to calculate latency.
  • FIG. 6A illustrates how the latency radius may be applied according to embodiments of the invention.
  • the system may receive an order entry from a network participant.
  • the system may query the latency radius.
  • the system may calculate the difference between the network participant's measured latency and the latency radius to obtain a latency differential.
  • the network participant's measured latency may be obtained from a stored value in step S502 of Figure 5 or it may be measured afresh at the time of order entry, depending on the desired configuration of the system.
  • the order may be sent to the market for execution immediately according to embodiments of the invention.
  • the order entry may be held to account for the difference between the network participant's latency and the latency radius and placed for execution once that difference in time has elapsed, depending upon the desired configuration of the system.
  • the system may transmit the order entry to network participant 1 ... q based on the latency differential.
  • FIG. 6B illustrates handling of order execution confirmations according to embodiments of the invention.
  • the system may receive an order execution confirmation.
  • the system may query the latency radius and may calculate the difference between the network participant' s latency and the latency radius to obtain the latency differential in step S634.
  • the system may measure the network participant's latency afresh or may use a previously obtained stored latency value, whichever is desired.
  • the system may transmit the order execution confirmation to the network participant based on the latency differential, such that the network participant may receive the order execution confirmation at the same time as a network participant with the latency radius.
  • FIG. 6C illustrates an example method for handling market data broadcasts according to embodiments of the invention.
  • the system may receive a market data broadcast.
  • the system may query the latency radius.
  • the system may calculate network participant's latency differentials by calculating the difference between the latency radius and the network participant's latency.
  • the market data may be transmitted to the network participant based on the latency differential, such that each network participant receives the market data information at approximately the same time.
  • FIGs. 6A-6C describe a programmable logic approach to applying the latency radius
  • implementations may employ a less-dynamic mechanical construction technique to apply the latency radius value.
  • the individual participant latency may be calculated by measuring the length of each fiber connection, such as using an OTDR, then physically placing the participant connection on a measured length of spooled fiber to introduce the desired latency in order to normalize latency across all market participants.
  • Latency radiuses may be on various scales, such as datacenter-wide, campus-wide, regional, national, etc.
  • the choice of physical versus logical latency control may be made at least in part based on the scale of the radius, using a different technique when the latency radius is 10ms than when the latency radius is ⁇ , for example.
  • a processing circuit includes a programmed processor (e.g., CPU 700).
  • a processing circuit/circuitry may also include devices such as an application specific integrated circuit (ASIC) and conventional circuit components arranged to perform the recited functions.
  • ASIC application specific integrated circuit
  • the processing circuitry may be referred to interchangeably as circuitry throughout the disclosure.
  • the processors in each of the servers are programmed to perform the processes described herein, they become special -purpose order routing devices.
  • the process performed by order router 104 as well as the other servers of the order routing system 100 are computationally rigorous due to the large amount of data that is processed in association with trading. For example, updating the realtime order statistics and historical data can involve processing gigabytes of data in real-time.
  • the servers of the order routing system 100 may use parallel processing to increase speed and efficiency.
  • the hardware described in connection with Figure 7 may apply to any of the hardware components of the order routing system 100, such as the inbound server 102, order router 104, and outbound server 106. Similarly, the hardware described in connection with Figure 7 may also apply to the customer interface server 212, the order management server 214, the trading notification server, 216, the execution platform 222, the order processing server 220, the market interface server 226, and the market trading server 224. Likewise, the hardware illustrated in Figure 7 may apply to the exchange interface server 314.
  • Implementation of the processes of the order routing system 100 on the hardware described herein improves the efficiency of routing orders to optimal market venues and determining the execution quality of the filled orders in real-time. Implementation of the processes of the order routing system 100 on the hardware described herein also improves the ability of the system to calculate the desired latency of a given order or partial order.
  • the example computing device includes a CPU 700 that may be configured to perform the processes described herein.
  • the process data and instructions may be stored in memory 702.
  • These processes and instructions may also be stored on a storage medium disk 704, such as a hard drive (HDD), solid state drive (SSD), or portable storage medium or may be stored remotely.
  • HDD hard drive
  • SSD solid state drive
  • CPU 700 may be a Xeon® or Intel Core® processor from Intel Corporation or an
  • Opteron processor from Advanced Micro Devices, Inc., or may be other processor types that would be recognized by one of ordinary skill in the art.
  • XEON and INTEL CORE are registered trademarks of Intel Corporation.
  • the CPU 700 may be implemented on an FPGA, ASIC, PLD, or using discrete logic circuits, as one of ordinary skill in the art would recognize. Further CPU 700 may be implemented as multiple processors cooperatively working in parallel to perform the instructions of the inventive processes described herein.
  • the computing device of Figure 7 also includes a network controller 706, such as an Intel® PRO Ethernet network interface card from Intel Corporation, for interfacing with a network 728, such as the customer network 114 or the market network 124 of Figure 1.
  • a network controller 706 such as an Intel® PRO Ethernet network interface card from Intel Corporation
  • the network 728 can be a public network, such as the Internet, or a private network such as a LAN or WAN network, or any computation thereof. It may also include PSTN or ISDN sub-networks.
  • the network 728 may also be wired, such as an Ethernet, Infiniband, or switched PCI network, or be wireless such as a cellular network, including EDGE, 3G, and 4G wireless cellular systems.
  • the wireless network can also be Wi-Fi®, Bluetooth®, or any other known wireless form of communication. (WI-FI is a registered trademark of Wi-Fi Alliance; BLUETOOTH is a registered trademark of Bluetooth SIG.)
  • the computing device further includes a display controller 708 for interfacing with a display 710 of the order router 104, such as an LCD monitor.
  • a general purpose I/O interface 712 at the order router 104 interfaces with a keyboard and/or mouse 714.
  • General purpose I/O interface 712 also connects to a variety of peripherals 718 including printers and scanners.
  • the general purpose storage controller 724 connects the storage medium disk 704 with communication interconnect 726, which may be an ISA, EISA, VESA, PCI, PCI express, point to point links, or similar, for interconnecting all of the components of the computing device.
  • communication interconnect 726 may be an ISA, EISA, VESA, PCI, PCI express, point to point links, or similar, for interconnecting all of the components of the computing device.
  • a description of the general features and functionality of the display 710, keyboard and/or mouse 714, as well as the display controller 708, storage controller 724, network controller 706, sound controller 720, and general purpose I/O interface 712 is omitted herein for brevity, since these features are known.
  • the computing device of Figure 7 is described as having a storage medium disk 704, the claimed advancements are not limited by the form of the computer-readable media on which the instructions of the inventive process are stored.
  • the instructions may be stored on CDs, DVDs, in FLASH memory, RAM, ROM, PROM, EPROM, EEPROM, hard disk or any other information processing device with which the computing device communicates.
  • claimed advancements may be provided as a utility application, background daemon, component of an operating system, or combination thereof, executing in conjunction with CPU 700 and an operating system such as Microsoft® Windows®, UNLX,
  • SOLARIS is a registered trademark of Oracle America, Inc.
  • LINUX is a registered trademark of Linus Torvalds
  • MAC OS is a registered trademark of Apple Corp.
  • processing features according to the present invention may be implemented and commercialized as hardware, a software solution, or a combination thereof.
  • instructions corresponding to the order routing process 400 and/or historical data generation process 500 in accordance with the present disclosure could be stored in a portable drive such as a USB Flash drive that hosts a secure process.

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)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention porte sur des systèmes et sur des procédés permettant d'adapter un flux d'ordre maintenu pour améliorer les performances d'exécution d'ordre, lesdits systèmes et procédés étant configurés de sorte à déterminer un rayon de latence pour des participants dans un ou plusieurs lieux de marché au fur et à mesure que des ordres sont traités par des lieux de marché (par exemple, des teneurs de marché, des systèmes de gestion parallèle (ATS pour Alternative Trading System) ou des échanges enregistrés). Le rayon de latence peut être utilisé pour créer un équilibre entre des participants au marché pour éliminer les avantages inhérents à des communications de marché à latence variable.
PCT/US2017/040980 2016-07-07 2017-07-06 Système, procédé et appareil permettant un accès impartial dans des lieux de marché Ceased WO2018009719A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662359350P 2016-07-07 2016-07-07
US62/359,350 2016-07-07

Publications (1)

Publication Number Publication Date
WO2018009719A1 true WO2018009719A1 (fr) 2018-01-11

Family

ID=60913198

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/040980 Ceased WO2018009719A1 (fr) 2016-07-07 2017-07-06 Système, procédé et appareil permettant un accès impartial dans des lieux de marché

Country Status (1)

Country Link
WO (1) WO2018009719A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090109959A1 (en) * 1996-11-18 2009-04-30 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
US20120246052A1 (en) * 2010-12-09 2012-09-27 Exegy Incorporated Method and Apparatus for Managing Orders in Financial Markets
US20130308495A1 (en) * 2005-02-23 2013-11-21 Coco Communications Corp. Secure, distributed hierarchical convergence network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090109959A1 (en) * 1996-11-18 2009-04-30 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
US20130308495A1 (en) * 2005-02-23 2013-11-21 Coco Communications Corp. Secure, distributed hierarchical convergence network
US20120246052A1 (en) * 2010-12-09 2012-09-27 Exegy Incorporated Method and Apparatus for Managing Orders in Financial Markets

Similar Documents

Publication Publication Date Title
US12217308B2 (en) In-order processing of network packets
US8898280B2 (en) Methods and apparatus for determining and displaying WAN optimization attributes for individual transactions
JP6892824B2 (ja) ネットワーク化されたコンピューティングリソースによるデータの協調した処理
AU2021202013B2 (en) System and method for executing synchronized trades in multiple exchanges
CA2500011A1 (fr) Procede et dispositif servant a effectuer une transaction equitable
KR20160145695A (ko) 트랜잭션을 위한 최신 정보를 제공하는 시스템들 및 방법들
US11489802B2 (en) System and method for regulating electronic message transmissions
US11863457B2 (en) Time-sensitive data delivery in distributed computing systems
WO2018009719A1 (fr) Système, procédé et appareil permettant un accès impartial dans des lieux de marché
JP4536026B2 (ja) ネットワーク品質測定方法、測定装置及びプログラム
US20200302526A1 (en) Make live at order processing system and method

Legal Events

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

Ref document number: 17824927

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17824927

Country of ref document: EP

Kind code of ref document: A1