WO2018009719A1

WO2018009719A1 - System, method, and apparatus for unbiased access in market venues

Info

Publication number: WO2018009719A1
Application number: PCT/US2017/040980
Authority: WO
Inventors: Kristofer SPINKA
Original assignee: Tradition America LLC
Current assignee: Tradition America LLC
Priority date: 2016-07-07
Filing date: 2017-07-06
Publication date: 2018-01-11
Anticipated expiration: 2019-01-07

Abstract

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.

Description

TITLE OF THE INVENTION

SYSTEM, METHOD, AND APPARATUS FOR UNBIASED ACCESS IN

MARKET VENUES

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 62/359,350, filed July 7, 2016, the contents of which are incorporated herein by reference.

BACKGROUND

[0002] 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. Typically, these orders are benchmarked against the current National Best Bid and Offer (NBBO) on arrival.

[0003] Existing retail order routing systems generally employ rigid routing schemes that process all orders for a given equity to a single venue participant or group of venue participants and are typically manually updated. Performance of these routing schemes is typically reviewed once per quarter using metrics as described in Security & Exchange Commission (SEC) Rule 605.

[0004] Existing systems are not optimal in that system latency, among other factors, may impact the time at which an order arrives at a market venue. Since market venues typically fill orders on a first in, first out (FIFO) methodology, keen participants in the market may detect a trading pattern before the held order can be completed. This represents a significant disadvantage because a keen participant, such as a high frequency trader, may manipulate the price of the security being traded before the order can be filled.

[0005] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely example aspects of the teachings of this disclosure and are not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more complete appreciation of this disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0007] Figure 1 is a block diagram of an example network topology of an order routing system, according to certain embodiments;

[0008] Figure 2 is a block diagram of an example processing module configuration of the order routing system of Figure 1;

[0009] Figure 3 is a block diagram of an example network topology of a market venue;

[0010] Figure 3 A is a block diagram of an example network topology of a market venue;

[0011] Figure 4 is a block diagram of an example network topology of a trading floor;

[0012] Figure 5 is a flow chart of an example latency radius calculation method according to certain embodiments of the invention;

[0013] Figure 6A is a flow chart of an example radius application method according to certain embodiments of the invention;

[0014] Figure 6B is a flow chart of an example latency radius application method according to certain embodiments of the invention;

[0015] Figure 6C is a flow chart of an example transmission method based on the latency radius according to certain embodiments of the invention;

[0016] Figure 7 is a block diagram of an example computing device.

[0017] In the drawings, like reference numerals designate identical or corresponding parts throughout the several views.

DETAILED DESCRIPTION

[0018] 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. [0019] Figure 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. The order routing systems communicates with customer devices 116, such as end retail investors and/or retail brokers, via a customer network 114. As such, 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). Further, although 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. Upon determining an appropriate route for the particular order, 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.

[0020] In some embodiments, the inbound server 102 receives customer inbound orders

118 placed by customers via the customer network 114. 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. In some examples, 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. For example, 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.

[0021] The outbound server 106, in some embodiments, 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).

[0022] As discussed further herein, the order router 104, in some embodiments, makes order routing decisions based on the real-time order statistics 128 as well as historical data 108. In one example, a database server (not illustrated) includes processing logic configured to process the historical data 108. In another example, 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.

[0023] Figure 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.

[0024] In some embodiments, 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.

[0025] The inbound server 102, in some embodiments, 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. In some embodiments, 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.

[0026] In addition to the order processing server 220, in some embodiments, 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. In one example, 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.

[0027] In some embodiments, the outbound server 106 of Figure 1 may include the exchange interface module 206. Within 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.

[0028] When the order is filled, in some embodiments, 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.

[0029] At the messaging data storage module 208, the trading notification server 216, in some embodiments, 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, for example, 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.

[0030] In some embodiments, 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) In some embodiments, latency may also be reduced by receiving feeds directly from an exchange.

[0031] In some embodiments, the data is communicated in FIX® format (Financial

Information eXchange) using FIX engines. (FIX is a registered trademark of Fix Protocol

Limited.) Some embodiments may also use order management systems. FAST (Fix Adapted for Streaming) may also be used in some embodiments. FAST uses compression to reduce message length, which reduces latency. Additionally, in some embodiments, the system may be configured for direct market access (DMA). DMA enables direct routing a securities order to a market venue 126. Other trading messaging formats and configurations are also within the scope of the present invention.

[0032] Figure 3 further illustrates a non-limiting example of the configuration of a market venue according to some embodiments of the invention. As shown in Figure 3, the market interface server 226 may send an inbound order 118 to order consolidator 302. In market venues which do not feature an 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.

[0033] In Figure 3, 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. For illustration purposes, 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.

[0034] Once the order has been filled, 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.

[0035] In the case of the information about inbound order 118 sent to the trade and quote database 312, it may then be sent to an exchange interface server 314. In some embodiments, 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.

[0036] Figure 3 A illustrates a market network configuration according to some embodiments of the invention. In the example of Figure 3 A, market interface server 226 may send inbound order 118 to an order entry gateway 340 of a market venue. Optionally, the order entry gateway 340 may acknowledge receipt of the order to the market interface server 226. From the order entry gateway 340, 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. From there, the inbound order 118 may be transmitted to the market venue 126 for execution. Once the order is filled, the filled order 120 may be transmitted from the market venue 126 to the market data interface 346. In turn, 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.

[0037] In some embodiments of Figure 3 A, the filled order information may be transmitted to a location other than market interface server 226. For example, the filled order information may be transmitted to other market venues. Additionally, in some embodiments of Figure 3 A, the market data interface 346 may communicate filled order 120 to market interface server 226, directly or via intermediaries.

[0038] Figure 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.

[0039] According to some implementations, 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. In some embodiments, 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.

[0040] As shown in Figure 5, 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. Additionally, in its discretion, 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.

[0041] In S502, 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.

[0042] In 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.

[0043] Although 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.

[0044] Avenue may have more than one latency radius. For example, there may be bilateral radiuses for simultaneous dissemination of executions. 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. In addition, the latency radius for different types of events may differ. For example, a latency radius for order books (quotes) may be different from the latency radius for executions or order entries. In some cases, the multiple latency radiuses may be independent, but in some cases the several latency radiuses may have constraints or dependencies between them. [0045] Although described in FIG. 5 as calculated from a single measurement of participant latency values, in some embodiments 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. In another example, moving averages may be employed and the latency radius may be constrained to be within a tolerance above or below the moving average. In yet another example, 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.

[0046] According to embodiments of the invention, latency can be measured as a roundtrip calculation or may be measured in a single direction. By way of example, 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. In the TCP protocol, 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. Because 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.

[0047] In embodiments of the invention, 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.

[0048] 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.

[0049] This calculated latency radius is therefore different from static latency buffers that apply a fixed latency for all data transfers for all venue participants. Similarly, because the latency radius is a calculated measured value, 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.

[0050] In some embodiments, the latency calculations or measurements may be performed at multiple logical layers of the connectivity stack. For example, the measurements may measure physical media by using optical time-domain reflectometer (OTDR) techniques, link- level measurements, and protocol -level measurements.

[0051] 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.

[0052] Figure 6A illustrates how the latency radius may be applied according to embodiments of the invention. In step S600, the system may receive an order entry from a network participant. In step S602, the system may query the latency radius. Then, in step S604, 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. Upon receipt of the order entry, in step S604, the order may be sent to the market for execution immediately according to embodiments of the invention. Alternatively, 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. In step S606, the system may transmit the order entry to network participant 1 ... q based on the latency differential.

[0053] Figure 6B illustrates handling of order execution confirmations according to embodiments of the invention. In step S630, the system may receive an order execution confirmation. In step S632, 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. In step S636, 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.

[0054] Figure 6C illustrates an example method for handling market data broadcasts according to embodiments of the invention. As shown in Figure 6C, in step S650, the system may receive a market data broadcast. In step S652, the system may query the latency radius. In step S654, the system may calculate network participant's latency differentials by calculating the difference between the latency radius and the network participant's latency. In step S656, 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.

[0055] Although 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. In such an embodiment, in which fiber optic connections are used to connect venue participants, 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.

[0056] 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.

[0057] Each of the functions of the described embodiments may be implemented by one or more processing circuits, as illustrated in the example of Figure 7. 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. The processing circuitry may be referred to interchangeably as circuitry throughout the disclosure. In addition, when 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. Additionally, the servers of the order routing system 100 may use parallel processing to increase speed and efficiency.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.) Alternatively, 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.

[0062] 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. (INTEL is a registered trademark of Intel Corporation.) As can be appreciated, 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.)

[0063] 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.

[0064] 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. 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.

[0065] Although 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. For example, 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.

[0066] Further, the 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®, LINUX®, Apple MAC OS®, and other systems known to those skilled in the art.

(MICROSOFT and WINDOWS are registered trademarks of Microsoft Corporation;

SOLARIS is a registered trademark of Oracle America, Inc., LINUX is a registered trademark of Linus Torvalds; and MAC OS is a registered trademark of Apple Corp.)

[0067] In other embodiments, processing features according to the present invention may be implemented and commercialized as hardware, a software solution, or a combination thereof. Moreover, 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.

[0068] A number of implementations have been described herein. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. For example, preferable results may be achieved if the steps of the disclosed techniques were performed in a different sequence, if components in the disclosed systems were combined in a different manner, of if the components were replaced or supplemented by other components. The functions, processes, and algorithms described herein may be performed in hardware or software executed by hardware, including computer processors and/or programmable circuits configured to execute program code and/or computer instructions to execute the functions, processes, and algorithms described herein. Additionally, an implementation may be performed on modules or hardware not identical to those described. Accordingly, other implementations are within the scope that may be claimed.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A system for providing unbiased access in market venues, comprising:

processing circuitry executing upon at least one computing device; and a non-transitory computer readable medium, coupled to the processing circuitry, storing machine-executable instructions including instructions operable when executed on the processing circuitry to cause the processing circuitry to:

receive an information for transmittal to a network participant;

measure a latency radius;

measure the network participant's latency;

calculate a difference between the network participant's latency and the latency radius to obtain a latency differential; and

transmit the information to the network participant based on the latency differential.

2. The system of claim 1, wherein the information is an order entry.

3. The system of claim 1, wherein the information is an order execution confirmation.

4. The system of claim 1, wherein the information is a market data broadcast.

5. The system of claim 1, wherein the instructions that when executed cause the processing circuitry to measure a latency radius comprise instructions that when executed cause the processing circuitry to:

(a) measure a participant latency between a selected network participant and a market venue;

(b) update the latency radius responsive to the participant latency being greater than the latency radius;

(c) retain the latency radius responsive to the participant latency not being greater than the latency radius; and

(d) output the latency radius,

wherein (a), (b), and (c) are performed for each network participant.

6. The system of claim 5, wherein the instructions that when executed cause the processing circuitry to retain the latency radius comprise instructions that when executed cause the processing circuitry to overwrite the latency radius with the same latency radius.

7. The system of claim 1, wherein the instructions that when executed cause the processing circuitry to measure the network participant's latency comprise instructions that when executed cause the processing circuitry to measure a round-trip latency for the network participant.

8. A non-transitory computer readable medium on which are stored instructions for providing unbiased access in market venues, comprising instructions that when executed cause processing circuitry to:

receive an information for transmittal to a network participant; measure a latency radius;

measure the network participant's latency;

9. The computer readable medium of claim 8, wherein the information is an order entry.

10. The computer readable medium of claim 8, wherein the information is an order execution confirmation.

11. The computer readable medium of claim 8, wherein the information is a market data broadcast.

12. The computer readable medium of claim 8, wherein the instructions that when executed cause the processing circuitry to measure a latency radius comprise instructions that when executed cause the processing circuitry to:

(d) output the latency radius,

wherein (a), (b), and (c) are performed for each network participant.

13. The computer readable medium of claim 8, wherein the instructions that when executed cause the processing circuitry to measure the network participant's latency comprise instructions that when executed cause the processing circuitry to measure a latency for the network participant in a single direction.

14. The computer readable medium of claim 8, wherein the instructions further comprise instructions that when executed cause the processing circuitry to re-measure the latency radius at a later time.

15. A method for providing unbiased access in market venues, comprising:

receiving an information for transmittal to a network participant; measuring a latency radius;

measuring the network participant's latency;

calculating a difference between the network participant's latency and the latency radius to obtain a latency differential; and

transmitting the information to the network participant based on the latency differential.

16. The method of claim 15, wherein the information is an order entry.

17. The method of claim 15, wherein the information is an order execution confirmation.

18. The method of claim 15, wherein the information is a market data broadcast.

19. The method of claim 15, wherein measuring a latency radius comprises:

(a) measuring a participant latency between a selected network participant and a market venue;

(b) updating the latency radius responsive to the participant latency being greater than the latency radius;

(c) retaining the latency radius responsive to the participant latency not being greater than the latency radius; and

(d) outputting the latency radius,

wherein (a), (b), and (c) are performed for each network participant.

20. The method of claim 15, wherein measuring the network participant's latency comprises measuring a round trip latency for the network participant.