WO2020148082A1

WO2020148082A1 - Normalization of signal processing latency

Info

Publication number: WO2020148082A1
Application number: PCT/EP2019/087175
Authority: WO
Inventors: Liam James SMITH; Maria Ioanna Stylianidi CHRISTODOULOU; Timothy Adrian RYLES
Original assignee: London Stock Exchange Plc
Priority date: 2019-01-14
Filing date: 2019-12-30
Publication date: 2020-07-23

Abstract

An example process to normalize signal processing latency of process signals submitted to a process signal executor. The process involves obtaining signal processing latency data at a process signal server. The signal processing latency data may indicate a delay between submission of a process signal to a process signal executor and receipt of the process signal by the process signal executor, or between receipt of the process signal by the process signal executor and execution of the process signal by the process signal executor. A client device is to build process signal generators to submit process signals to the process signal executor. The process further involves providing the signal processing latency data to a client device for display or to be incorporated into a simulation of a process signal generator being run. Processor load balancing at the process signal server is also described.

Description

NORMALIZATION OF SIGNAL PROCESSING LATENCY

FIELD

[0001] The present disclosure relates to signal processing.

BACKGROUND

[0002] Signal processing may involve the transmission and receipt of process signals over a network. The transmission of process signals over the network may be subject to delays caused by a multitude of network factors. Such network factors may include the physical distance that a process signal travels to reach its destination, software or hardware bottlenecks in network devices, or other factors. The delay between the transmission of a process signal over a network and its receipt at its intended destination may be termed network latency.

[0003] Signal processing may also involve the processing of a process signal at a destination computing device. The processing of a process signal at a computing device may be subject to delays caused by processor overload. That is, the processing power available to a computing device may not be sufficient to process all incoming process signals immediately. Some process signals may be delayed while others are being processed. The delay between the receipt of a process signal at a computing device and its execution on the computing device may be termed processor latency. Together, network latency and processor latency may be termed signal processing latency.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a schematic diagram of an example system for normalizing signal processing latency. [0005] FIG. 2 is a schematic diagram of an example system for normalizing signal processing latency in the trade of financial instruments.

[0006] FIG. 3 is a schematic diagram of an example user interface for building trading algorithms.

[0007] FIG. 4 is a schematic diagram of another example system for normalizing signal processing latency.

[0008] FIG. 5 is a schematic diagram of another example system for normalizing signal processing latency in the trade of financial instruments.

[0009] FIG. 6 is a schematic diagram of another example user interface for building trading algorithms.

[0010] FIG. 7 is a schematic diagram of yet another example system for normalizing signal processing latency.

[0011] FIG. 8 is a schematic diagram of yet another example system for normalizing signal processing latency in the trade of financial instruments.

[0012] FIG. 9 is a schematic diagram of an example user interface element for building a trading algorithm to be simulated on historical trading data.

[0013] FIG. 10 is a schematic diagram of another example user interface element for building a trading algorithm.

[0014] FIG. 11 is a schematic diagram of an example user interface element for displaying market trading data.

[0015] FIG. 12 is a schematic diagram of an example user interface element for displaying a comparison of trading algorithms applied to different financial instruments.

[0016] FIG. 13 is a schematic diagram of an example user interface element for displaying a chart showing changes in aspects of a trading algorithm over time. DETAILED DESCRIPTION

[0017] In a large system reliant on the processing of process signals transmitted by a plurality of differently situated process signal originators, delays in the processing of a process signal may be manipulated to the benefit of some process signal originators at the expense of others. The manipulation may include the manipulation of network latency or processor latency. For example, one may reduce the physical distance of one process signal originator from the destination computing device to reduce the network latency experienced by the process signal originator so that its process signals are executed more quickly than those of other originators. As another example, one process signal originator may structure its process signals in such a way that causes the destination computing device to favour its process signals over the process signals of other originators to reduce the processor latency it experiences so that its process signals are executed more quickly than those of other

originators. Such manipulation may cause undesirable effects in the system.

[0018] A system and process may be provided to normalize signal processing latency by providing signal processing latency data to process signal originators. The signal processing latency data may be used for display at a process signal originator to assist in the building of a process signal generator. The signal processing latency data may also be incorporated into simulations of a process signal generator being run. Thus, process signal generators may be designed to compensate for signal processing latency.

[0019] Further, a system and process may be provided to normalize signal processing latency by balancing processor load at the destination computing device.

[0020] Such systems and processes may be applied to any system in which a plurality of process signals are transmitted by a plurality of process signal originators which are differently situated in a way which is relevant to signal processing latency. For example, such processes may be applied in the field of trading financial instruments, in which a plurality of market participants submit trade orders for processing at a trading exchange. In such examples, trade orders may be submitted directly from a client device controlled by a market participant, such as an individual or an institution, or may be submitted by a trading algorithm at the client device. Further, in such examples, trade orders may be submitted indirectly via generation by a trading algorithm and submitted to the trading exchange by a trading algorithm server. In the application to the trade of financial instruments, signal processing latency may be normalized to reduce or disincentivize trade arbitrage, or to reduce the effectiveness of trade arbitrage, to enable a broader set of market participants to participate effectively in the trade of financial instruments.

[0021] It is emphasized that the processes discussed herein may be applied to any system in which a plurality of process signals are transmitted by a plurality of differently situated process signal originators.

[0022] FIG. 1 is a schematic diagram of such an example system 100 for normalizing signal processing latency. The system 100 includes a process signal executor 130, a process signal server 120, and a client device 110. The process signal executor 130 executes process signals (“PS”). The process signal server 120 processes process signals and submits process signals to the process signal executor 130 for execution. In some examples, the process signal server 120 may include a process signal generator for generating process signals for submission to the process signal executor 130.

[0023] The ultimate processing of a process signal at the process signal executor 130 may be delayed in several ways. For example, there may be a delay between submission of a process signal to the process signal executor 130 and receipt of the process signal by the process signal executor 130. As another example, there may be a delay between receipt of a process signal by the process signal executor 130 and execution of the process signal by the process signal executor 130. As yet another example, there may be a delay between submission of a process signal to the process signal server 120 and the receipt of the process signal at the process signal server 120. As yet another example, there may be a delay between receipt of a process signal by the process signal server 120 and the processing and submission of the process signal to the process signal executor 130. Any of such delays, or combination of such delays, may be included in signal processing latency data (“SPLD”).

[0024] The process signal server 120 obtains signal processing latency data and provides the signal processing latency data to the client device 110.

[0025] The client device 110 is to run a user interface 112 to display a signal processing latency display component 114. The signal processing latency display component 114 is to display the signal processing latency data. Thus, a user of the client device 1 10 may monitor signal processing latency. The user interface 112 is further to display a process signal generator builder component 116 operable to build a process signal generator to generate process signals for submission to the process signal executor 130. Thus, process signal generators may be designed to compensate for signal processing latency.

[0026] Although only a single client device 110 is shown, it is to be

understood that other systems similar to the system 100 may include a plurality of client devices 110. Further, in such examples, each client device 1 10 may be differently situated with respect to the process signal server 120 and/or process signal executor 130, and therefore may experience different latency effects when in communication with the process signal server 120 and/or process signal executor 130. Thus, different client device 110 may be provided with signal processing latency data to enable the client devices 1 10 to compensate for differences in process signal latency, including to enable the client devices 110 to build process signal generators differently to compensate for differences in process signal latency.

[0027] The system 100 may be applied to any system in which a plurality of process signals are transmitted by a plurality of differently situated process signal originators. For example, such processes may be applied in the field of trading financial instruments, in which a plurality of trade orders are submitted for processing at a trading exchange. Such an example system is described with reference to FIG. 2.

[0028] FIG. 2 is a schematic diagram of an example system 200 for normalizing signal processing latency in the trade of financial instruments. The system 200 includes client devices 210, a trading algorithm server 220, and a trading exchange 230. The client devices 210 and the trading algorithm server 220 are in communication via one or more computing networks, indicated as network 240. The trading algorithm server 220 is in direct communication with the trading exchange 230.

[0029] A client device 210 may include any computing device having memory, communication, and processing capability. Thus, a client device 210 may include a desktop computer, a smartphone, a server, or another computing device. A client device 210 is to run a trading algorithm builder 212 which allows a user of the client device 210 to build trading algorithms to conduct trading of financial instruments at the trading exchange 230. A controller of the trading actions of a client device 210, such as a user, an institution, or a trading algorithm, may be termed a market participant. Thus, in general, reference to the trading actions of client devices 210 may be had when referring to the trading actions of market participants, and vice versa.

[0030] Further, a client device 210 is to run a user interface to display a trade latency display component to display the trade latency data 226. The user interface is further to display a trading algorithm builder component operable to build a trading algorithm to generate trade orders for submission to the trading exchange 230. Although it is shown that a single client device 210 is to run a trading algorithm builder 212, it is to be understood that other client devices 210 may also run other instances of a trading algorithm builder 212.

[0031] The trading algorithm builder 212 may be instantiated in any non- transitory machine-readable storage medium. Thus, the trading algorithm builder 212 may be instantiated in software, firmware, a combination of such and similar. [0032] A client device 210 may also run software to generate and submit individual trades to be executed at the trading exchange 230.

[0033] The trading algorithm server 220 may include any computing device having memory, communication, and processing capability. The trading algorithm server 220 hosts a plurality of client accounts 222 associated with client devices 210. Each client account 222 may be associated with one or more trading algorithms 224 built by a user of a client device 210 using the trading algorithm builder 212.

[0034] The trading algorithm server 220 further stores trade latency data 226. The trade latency data 226 may include data indicating network latency or processor latency associated with the processing of trader orders at the trading exchange 230. For example, the trade latency data 226 may include a delay between submission of a trade order to the trading exchange 230 and receipt of the trade order by the trading exchange 230. As another example, the trade latency data 226 may include a delay between receipt of a trade order by the trading exchange 230 and execution of the trade order by the trading exchange 230. As yet another example, the trade latency data 226 may include a delay between submission of a trade order to the trading algorithm server 220 and receipt of the trade order at the trading algorithm server 220. As yet another example, the trade latency data 226 may include a delay between receipt of a trade order by the trading algorithm server 220 and submission of the trade order to the trading exchange 230.

[0035] Further, the trade latency data 226 may include current trade latency information about the currently estimated time delay to be experienced by one or more client devices 210 when transmitting information, such as newly built trading algorithms 224, updates to existing trading algorithms 224, or direct trades, to the trading algorithm server 220 and/or the trading exchange 230 (i.e. “My Current Trade Latency”). The trade latency data 226 may further include the current average or aggregate trade latency experienced by all or a subset of the client devices 210 (i.e.“Aggregate Current Trade Latency”). The trade latency data 226 may further include historical trade latency information, such as the historical time delay experienced by a client device 210 when submitting trades, or the average or aggregate historical trade latency experienced by all or a subset of client devices 210.

[0036] The trade latency data 226 may be displayed numerically, graphically, or in text. For example, the trade latency data 226 may be displayed in the form of an alphanumeric statement, such as“My Current Trade Latency: 43 ms” to indicate that the user’s current trade latency is estimated to be 43 milliseconds. As another example, the trade latency data 226 may be displayed graphically in a chart which shows a distribution of trade latencies experienced by other client devices 210, and indicates where a particular client device 210 is situated on the distribution. As yet another example, the trade latency data 226 may be displayed qualitatively. For example, the trade latency data 226 may be represented by colour-coded images or icons, such as a green icon to indicate low latency, a yellow icon to indicate moderate latency, and a red icon to indicate high latency. Such qualitative indicia may be displayed to represent the trade latency experienced by a particular client device 210 or all or a subset of client devices 210.

[0037] The trading algorithm server 220 further includes a trade latency data manager 227 to obtain trade latency data 226 and to determine which trade latency data 226 is to be provided to client devices 210. The trade latency data manager 227 provides the trade latency data 226 to a client device 210, such as by, for example, transmission over the network 240.

[0038] The trade latency data 226 determined to be provided to client devices 210 may be the trade latency data 226 relevant to trading algorithm being built by the trading algorithm builder 212. The trade latency data 226 may include a delay associated with a first client device 210 or client account 222 as compared to a delay of a second client device 210 or client account 22. Thus, a user of a client device 210 may build a trading algorithm in view of the latency experienced by the user in comparison to that experienced by other users, and may thereby compensate for any difference in latency.

[0039] Thus, different client devices 210 may be differently situated with respect to the trading algorithm server 220 and/or trading exchange 230, and therefore may experience different latency effects when communication with the trading algorithm server 220 and/or trading exchange 230. Thus, different client device 210 may be provided with signal processing latency data to enable trading algorithms 224 to be differently built to compensate for differences in process signal latency. The trading algorithm server 220 further includes a trade submission module 228. The trade submission module 228 obtains trade orders generated by trading algorithms 224 and submits the trade orders to the trading exchange 230 for execution.

[0040] In some examples, the trading algorithm server 220 may further obtain market trading data indicating trading on the trading exchange 230 and provide the market trading data to a client device 210. The market trading data may be obtained from data feeds from the trading exchange 230, or from historical data stores. Further, a client device 210 may run a user interface to display a market trading data display component to display the market trading data. The market trading data display component may be visually adjacent to the trade latency data display component for ease of reference to a user building a trading algorithm.

[0041] In some examples, the trading algorithm server 220 may transmit notifications to client devices 210 that certain market opportunities have arisen. In other words, a trading algorithm 224 may be designed to automatically generate and transmit a notification to a client device 210 associated with a client account 222 when a pre-determ ined market condition is met. Thus, while some trading algorithms 224 may be programmed to automatically conduct trades with the trading exchange 230 when certain market conditions are met, some trading algorithms may be programmed to automatically issue

notifications when certain market conditions are met. Such notifications may include market trading data and/or trade latency data. For example, a

notification may include the information that a certain financial instrument has surpassed a pre-determ ined price threshold. In another example, a notification may include the information that the trade latency over the network 240 or between the trading algorithm server 220 and trading exchange 230 has surpassed a pre-determ ined latency threshold. Thus, for example, a user may be notified when trade latencies are low, indicating a preferable window of time within which trades may be conducted.

[0042] FIG. 3 is a schematic diagram of an example user interface 300 for building trading algorithms. The user interface 300 includes a trading algorithm builder component 310 operable to build a trading algorithm. The trading algorithm builder component 310 includes an instrument selection component 312 to select a financial instrument to be included in a trading algorithm. The trading algorithm builder component 310 further includes a timeframe selection component 314 to define a timeframe during which a trading algorithm is to be run. The trading algorithm builder component 310 further includes a build action component 316 and a sell action component 318 to build triggers and events for build actions and sell actions respectively. The build action component 316 and sell action component 318 may allow the selection and/or input of logical operands, financial instrument symbols, numerical values, and other algorithmic components to build a trading algorithm. Thus, the buy action component 316 may be used to build buy actions for buying a financial instrument when certain conditions are met, and the sell action component 318 may be used to build sell actions for selling a financial instrument when certain conditions are met. The buy action component 316 and sell action component 318 may provide options for designing buy and sell actions based on comparisons, such as the

comparison of one aspect of a financial instrument to a numerical value or to an aspect of another financial instrument. For example, a buy action may be configured to submit a buy order for a particular financial instrument when the previous closing price of the financial instrument is less than or equal to the previous weeks’ average close price, within a tolerance of 1 %. Multiple conditions may be combined using logical operands such as“and” or“or” operators. The user interface 300 further includes a save button 320 to store in memory a trading algorithm built using the trading algorithm builder component 310.

[0043] The user interface 300 further includes a trade latency display component 330 to display trade latency data. The trade latency data may be displayed as, for example, a real-time latency, an average latency, and/or a comparison of the latency of one or more users against the latency of one or more other users. The trade latency data displayed may include any trade latency as discussed herein, including network latency, processing latency, or a combination thereof. Thus, a user of the user interface 300 may design a trading algorithm to compensate for such trade latencies.

[0044] In some examples, the user interface 300 may include a market trading data display component to display market trading data. The market trading data display component may be visually adjacent to the trade latency data display component for ease of reference to a user building a trading algorithm.

[0045] In some examples, the user interface 300 may include tutorial elements to teach a user how to use the user interface 300. For example, each component may include a tooltip to explain the function of the component. As another example, the user interface 300 may include a chatbot which may respond to questions asked by a user. A chatbot may actively engage the user to teach the user about elements of the user interface 300.

[0046] FIG. 4 is a schematic diagram of another example system 400 for normalizing signal processing latency. The system 400 may be similar to the system 100 of FIG. 1 , with like elements numbered in a“400” series rather than a“100” series, and thus includes a process signal executor 430, a process signal server 420, and a client device 410. For further description of the above elements, the description of system 100 of FIG. 1 may be referenced. [0047] The process signal executor 430 executes process signals. The process signal server 420 obtains signal processing latency data which includes one or more delays as described with reference to FIG. 1. The process signal server 420 provides the signal processing latency data to the client device 410. The client device 410 is to run a user interface 412 to display a process signal generator builder component 416 operable to build a process signal generator to generate process signals for submission to the process signal executor 430.

[0048] The process signal server 420 further obtains process signal execution data (“PSED”), which indicates execution of process signals on a process signal executor 430. The process signal execution data may be obtained from data feeds from the process signal executor 430, or from historical data stores. Further, the user interface 412 is further to display a process signal execution simulation component 414 operable to display a result of a simulation of running of the process signal generator based on the process signal execution data, the simulation incorporating the delay. Thus, process signal generators may be designed to compensate for signal processing latency. It is to be understood that although the process signal execution simulation component 414 is situated on the user interface 412, the simulation processing may take place elsewhere on the client device 410, or on a remote computing device, such as the process signal server 420.

[0049] The process signal execution simulation component 414 may display the results of the simulations of running different process signal generators. Further, the process signal execution simulation component 414 may display comparisons of results of running different process signal generators.

[0050] The system 400 may be applied to any system in which a plurality of process signals are transmitted by a plurality of differently situated process signal originators. For example, such processes may be applied in the field of trading financial instruments, in which a plurality of trade orders are submitted for processing at a trading exchange. Such an example system is described with reference to FIG. 5. [0051] FIG. 5 is a schematic diagram of another example system 500 for normalizing signal processing latency in the trade of financial instruments. The system 500 may be similar to the system 200, with like elements numbered in a “500” series rather than a“200” series, and therefore includes client devices 510 to run trading algorithm builders 512, a trading algorithm server 520 to host a plurality of client accounts 522, trading algorithms 524, trade latency data 526, a trade latency data manager 527, and a trade submission module 528, and includes a trading exchange 530 and a network 540. For further description of the above elements, the description of system 200 of FIG. 2 may be referenced.

[0052] The trading algorithm server 520 further hosts historical trading data 529 indicating market trades on the trading exchange 530. For example, the historical trading data 529 may include lists of financial instrument pricing at particular time stamps over a period of time. The historical trading data 529 may further include trade orders on order books at particular time stamps. Further, a trading algorithm builders 512 may further include a user interface to display a trading algorithm simulation component operable to display a result of a simulation of running of the trading algorithm based on the historical trading data 529. Further, the simulation may incorporate trade latency data 526 into the simulation. Thus, a user of a trading algorithm builder 512 may test trading algorithms against historical market trading data under simulated latency effects.

[0053] FIG. 6 is a schematic diagram of another example user interface 600 for building trading algorithms. The user interface 600 may be similar to the user interface 300 of FIG. 3, with like elements numbered in a“600” series rather than a“300” series, and therefore includes a trading algorithm builder

component 610, an instrument selection component 612, a timeframe selection component 614, a buy action component 616, a sell action component 618, and a save button 620. For further description of the above elements, the description of the user interface 300 of FIG. 3 may be referenced. [0054] The user interface 600 further includes an algorithm simulation component 640 operable to display a result of a simulation of running of the trading algorithm based on historical trading data and incorporating trade latency data into the simulation. The algorithm simulation component 640 may display a simulated latency, average latencies on the market, comparisons of different latencies, and may display a result of running the trading algorithm, such as a final investment value after a trading algorithm has run for a certain timeframe. Thus, a user of the user interface 600 may test trading algorithms against historical market trading data under simulated latency effects. The simulated latency effects may include network latency, processing latency, or a combination thereof.

[0055] The algorithm simulation component 640 may display the results of the simulations of running different trading algorithms. Further, the algorithm simulation component 640 may display comparisons of results of running different trading algorithms. Such simulations may be run, and the results may be compared, based on current or historical market trading data, and further may be based on simulated latency effects.

[0056] FIG. 7 is a schematic diagram of yet another example system 700 for normalizing signal processing latency. The system 700 may be similar to the system 100 of FIG. 1 , with like elements numbered in a“700” series rather than a“100” series, and thus includes a process signal executor 730 and a process signal server 720. For further description of the above elements, the description of system 100 of FIG. 1 may be referenced.

[0057] The process signal server 720 further includes a first process signal generator 750, a second process signal generator 752, and a processor load 722. The process signal server 720 obtains a first process signal (“PS 1”) submitted by the first process signal generator 750 and a second process signal (“PS 2”) submitted by the second process signal generator 752.

[0058] The process signal server 720 determines the processor load 722 available to process the first process signal and the second process signal. The process signals are processed at the process signal server 720 for submission to the process signal executor 730. The process signal server 720 assigns processor load 722 to process the first process signal and the second process signal to balance distribution of the processor load 722 available between the first process signal and the second process signal. Thus, neither the first process signal nor the second process signal is favored for processing.

[0059] After processing the first process signal, the process signal server 720 submits the first process signal to the process signal executor 730 for execution. After processing the second process signal, the process signal server 720 submits the second process signal to the process signal executor 730 for execution. Thus, processor latency is normalized between the first process signal and the second process signal, and neither the first process signal nor the second process signal is favored for submission to the process signal executor 730.

[0060] In some examples, the process signal server 720 may balance distribution of processor load 722 to synchronize submission of the first process signal and the second process signal to the process signal executor 730 for simultaneous execution by the process signal executor 730.

[0061] The system 700 may be applied to any system in which a plurality of process signals are transmitted by a plurality of differently situated process signal originators. For example, such processes may be applied in the field of trading financial instruments, in which a plurality of trade orders are submitted for processing at a trading exchange. Such an example system is described with reference to FIG. 8.

[0062] FIG. 8 is a schematic diagram of yet another example system 800 for normalizing signal processing latency in the trade of financial instruments. The system 800 may be similar to the system 200, with like elements numbered in a “800” series rather than a“200” series, and therefore includes client devices 810 to run trading algorithm builders 812, a trading algorithm server 820 to host a plurality of client accounts 822, trading algorithms 824, and a trade submission module 828, and the system 800 further includes a trading exchange 830 and a network 840. For further description of the above elements, the description of system 200 of FIG. 2 may be referenced.

[0063] The trading algorithm server 820 further includes a processor load balancer 825 to balance processing of trade orders submitted by trading algorithms 824. Thus, the processor load balancer 825 obtains a first trade order submitted by a first trading algorithm 824 and a second trade order submitted by a second trading algorithm 824. The processor load balancer 825 determines processor load available to process the first trade order and the second trade order for submission to the trading exchange 830. The processor load balancer 825 assigns processor load to process the first trade order and the second trade order to balance distribution of the processor load available between the first trade order and the second trade order. The processor load balancer 825 may be implemented in many ways, including in hardware, firmware, or software, and may allocate processing power to process incoming trade orders in other ways.

[0064] After processing the first trade order and the second trade order, the first and second trade orders are submitted to the trading exchange 830 for execution. Thus, processor latency is normalized between the first and second trade orders, and thereby between the first and second trading algorithms 824, and neither is favored for submission to the trading exchange 830.

[0065] In some examples, the process load balancer 825 may balance distribution of processor load to synchronize submission of the first trade order and the second trade order to the trading exchange 830 for simultaneous fulfillment by the trading exchange 830.

[0066] FIG. 9 is a schematic diagram of an example user interface element 900 for building a trading algorithm to be simulated on historical trading data. The user interface element 900 may be used to select a financial instrument to be traded, a quantity of the financial instrument to be traded, a point in time at which the financial instrument is to be traded, and a timeframe during which the trading algorithm is to run. The user interface element 900 may be used in conjunction with a user interface element to build or select a trading algorithm to be simulated based on the options selected in the user interface element 900. Additional option buttons include a button to automatically reinvest gains earned by the trading algorithm. Further, the user interface element 900 includes buttons to select interday strategies and intraday strategies of the trading algorithm.

[0067] FIG. 10 is a schematic diagram of another example user interface element 1000 for building a trading algorithm. The user interface element 1000 includes a buy action component 1016 to build buy actions for buying a financial instrument when certain conditions are met, and a sell action component 1018 to build sell actions for selling a financial instrument when certain conditions are met. The buy action and sell action components 1016, 1018, may provide screens for designing buy and sell actions based on when certain comparisons are satisfied, such as the comparison of one aspect of a financial instrument to a numerical value or to an aspect of another financial instrument. For example, a buy action may be configured to submit a buy order for a particular financial instrument when the previous closing price of the financial instrument is less than or equal to the previous weeks’ average close price, within a tolerance of 1 %. Multiple conditions may be combined using logical operands such as“and” or“or” operators. Further, the buy action and sell action components 1016,

1018, may provide screens for designing buy and sell actions based on whether a number of gain or loss days is met. Similarly, multiple conditions may be combined using logical operands. Further, the buy action and sell action components 1016, 1018 may provide screens for designing buy and sell actions based on a number of financial instruments previously sold. For example, a buy action may be configured to automatically buy a financial instrument if, at the end of the trading day, none of the financial instrument is owned. Further, the user interface element 1000 may provide a button for automatically generating a trading algorithm which is an inverse of a currently selected trading algorithm. Moreover, any of the above conditions may be combined as logical blocks. For example, a comparison condition may be combined with a number of gains & loss days condition. Logical blocks may be evaluated according to any suitable algorithm, such as left-wise binding, and with or without block nesting.

[0068] FIG. 11 is a schematic diagram of an example user interface element 1100 for displaying market trading data. The user interface element 1100 may include a plot showing changes in aspects of a trading algorithm over time, such as the opening price, closing price, net return, open five day average, close five day average, number of trades, total traded consideration, total traded volume, or any other aspects of a trading algorithm of interest, over a period of minutes, hours, days, weeks, months, years, or any other suitable timeframe. For example, the user interface element 1100 may display the number of round trip trades executed pursuant to a trading algorithm, which may be indicated by the number of buy trades executed (i.e.“Buy Trades : 210”) and sell trades executed (i.e.“Sell Trades: 2010).

[0069] FIG. 12 is a schematic diagram of an example user interface element 1200 for displaying a comparison of a trading algorithm applied to different financial instruments. The user interface element 1200 includes a radar chart displaying a first dataset 1202 corresponding to the outcomes of the application of a trading algorithm to a first financial instrument and a second dataset 1204 corresponding to the outcomes of the application of a trading algorithm to a second financial instrument. The dimensions or axis of the radar chart may correspond to different outcomes of the application of various strategic or tactical aspects of a trading algorithm. For example, the maximum number of shares of a first financial instrument owned may be compared against the maximum number of shares of a second financial instrument owned. As another example, the minimum sell price at which each financial instrument is to be sold pursuant to a trading algorithm may be compared, and the minimum buy price at which each financial instrument is to be purchased pursuant to the trading algorithm may be compared. As another example, the final cash balance of the value held in each financial instrument after application of the trading algorithm may be compared. As yet another example, the number of buy transactions or sell transactions executed by a trading algorithm on one financial instrument versus another financial instrument may be compared. As can be seen in FIG. 12, a comparison of the first dataset 1202 to the second dataset 1204 on the radar chart indicates that the first financial instrument has had fewer sell actions and fewer buy actions executed against it than the second financial instrument. Such differences may be the result of different market trading conditions, such as price, volume, and trade activity taking place differently for each financial instrument. Although two datasets are shown, it is contemplated that three or more datasets may be compared in this way. Further, it is contemplated that a single dataset may be displayed on the radar chart for evaluation of a trading algorithm on a particular financial instrument.

[0070] FIG. 13 is a schematic diagram of an example user interface element 1300 for displaying a chart showing changes in aspects of a trading algorithm over time. The user interface element 1300 displays a chart plot showing the change in outcomes of a trading algorithm, such as the number of shares owned, the number of transactions, the net assets, the daily investment, the gains/loss, the cash balance, the closing price, or any other aspects of a financial instrument of interest, over a period of minutes, hours, days, weeks, months, years, or any other suitable timeframe. The cash balance lines 1302 indicates the entry points and exit points into trades.

[0071] Thus, systems and processes may be provided which normalize the processing of process signals from differently situated process signal

originators. Process signal generators may be designed to compensate for signal processing latency, and processing load may be balanced between the process signals generated by different process signal generators. Such systems and processes may be applied to any system in which a plurality of process signals are transmitted by a plurality of differently situated process signal originators, such as in the trading of financial instruments.

[0072] Although the specification has described certain example systems, processes, devices, user interfaces, user interface elements, and other features, it is to be understood that various combinations of such example systems, methods, devices, user interfaces, user interface elements, and other features not explicitly shown are also contemplated to be within the scope of the present specification. For example, any user interface, user interface element, or portion thereof, may be combined with any other user interface, user interface element, or portion thereof, to generate a larger user interface, user interface element, or portion thereof.

[0073] The scope of the claims should not be limited by the above examples but should be given the broadest interpretation consistent with the description as a whole.

Claims

1. A process comprising: obtaining signal processing latency data at a process signal server, the signal processing latency data indicating a delay between one or more of: submission of a process signal to a process signal executor and receipt of the process signal by the process signal executor; receipt of the process signal by the process signal executor and execution of the process signal by the process signal executor; submission of a process signal to the process signal server and receipt of the process signal at the process signal server; and receipt of a process signal by the process signal server and submission of the process signal to the process signal executor; and providing the signal processing latency data to a client device, the client device to run a user interface to display a signal processing latency display component to display the signal processing latency data, the user interface further to display a process signal generator builder component operable to build a process signal generator to generate process signals for submission to the process signal executor.

2. The process of claim 1 , wherein the signal processing latency data comprises trade latency data, the process signal server comprises a trading algorithm server, the process signal comprises a trade order, the process signal executor comprises a trading exchange, the signal processing latency display component comprises a trade latency display component, and the process signal generator builder component comprises a trading algorithm builder component.

3. The process of claim 2, wherein the delay is between submission of the trade order to the trading exchange and receipt of the trade order by the trading exchange.

4. The process of claim 2, wherein the delay is between receipt of the trade order by the trading exchange and execution of the trade order by the trading exchange.

5. The process of any one of claims 3 to 4, wherein the delay comprises a currently estimated time delay.

6. The process of any one of claims 3 to 4, wherein the delay comprises a historical time delay.

7. The process of any one of claims 2 to 6, further comprising: obtaining market trading data indicating trading on the trading exchange; and providing the market trading data to the client device, the client device to run the user interface to display a market trading data display component to display the market trading data.

8. The process of any one of claims 2 to 7, further comprising submitting a trade order generated by the trading algorithm built by the trading algorithm builder component to the trading exchange.

9. The process of any one of claims 2 to 8, further comprising maintaining a plurality of client accounts, each client account to link to a trading algorithm built by a trading algorithm builder component.

10. The process of any one of claims 2 to 9, wherein the trade latency data comprises delays associated with a plurality of market participants, and wherein the trade latency display component displays a delay associated with a first market participant of the plurality of market participants compared to a delay associated with a second market participant of the plurality of market

participants.

11. A process comprising: obtaining process signal execution data at a process signal server, the process signal execution data indicating execution of process signals on a process signal executor; obtaining signal processing latency data at the process signal server, the signal processing latency data indicating a delay between one or more of: submission of a process signal to the process signal executor and receipt of the process signal by the process signal executor; receipt of the process signal by the process signal executor and execution of the process signal by the process signal executor; submission of a process signal to the process signal server and receipt of the process signal at the process signal server; and receipt of a process signal by the process signal server and submission of the process signal to the process signal executor; and providing the signal processing latency data to a client device, the client device to run a user interface to display a process signal generator builder component operable to build a process signal generator to generate process signals for submission to a process signal executor, the user interface further to display a process signal execution simulation component operable to display a result of a simulation of running of the process signal generator based on the process signal execution data, the simulation incorporating the delay.

12. The process of claim 11 , wherein the process signal execution data comprises market trading data, the process signal server comprises a trading algorithm server, the process signal comprises a trade order, the process signal executor comprises a trading exchange, the signal processing latency data comprises trade latency data, the process signal generator builder component comprises a trading algorithm builder component, and the process signal execution simulation component comprises a trading algorithm simulation component.

13. The process of claim 12, wherein the delay is between submission of the trade order to the trading exchange and receipt of the trade order by the trading exchange.

14. The process of claim 12, wherein the delay is between receipt of the trade order by the trading exchange and execution of the trade order by the trading exchange.

15. The process of any one of claims 13 to 14, wherein the delay comprises a currently estimated time delay.

16. The process of any one of claims 13 to 14, wherein the delay comprises a historical time delay.

17. The process of any one of claims 12 to 16, further comprising: providing the market trading data to the client device, the client device to run the user interface to display a market trading data display component to display the market trading data.

18. The process of any one of claims 12 to 17, further comprising submitting a trade order generated by the trading algorithm built by the trading algorithm builder component to the trading exchange.

19. The process of any one of claims 12 to 18, further comprising maintaining a plurality of client accounts, each client account to link to a trading algorithm built by a trading algorithm builder component.

20. The process of any one of claims 12 to 19, wherein the trade latency data comprises delays associated with a plurality of market participants, and wherein the trading algorithm simulation component incorporates a delay associated with a first market participant of the plurality of market participants compared to a delay associated with a second market participant of the plurality of market participants.

21. A process comprising: obtaining, at a process signal server, a first process signal submitted by a first process signal generator; obtaining, at the process signal server, a second process signal submitted by a second process signal generator; determining processor load available at the process signal server to process the first process signal and the second process signal for submission to a process signal executor; assigning processor load to process the first process signal and the second process signal to balance distribution of the processor load available between the first process signal and the second process signal; after processing the first process signal, submitting the first process signal to the process signal executor for execution; and after processing the second process signal, submitting the second process signal to the process signal executor for execution.

22. The process of claim 21 , wherein the first process signal comprises a first trade order, the first process signal generator comprises a first trading algorithm, the second process signal comprises a second trade order, the second process signal generator comprises a second trading algorithm, and the process signal executor comprises a trading exchange.

23. The process of claim 22, further comprising maintaining a plurality of client accounts including a first client account associated with the first trading algorithm and a second client account associated with the second trading algorithm.

24. The process of any one of claims 22 to 23, further comprising synchronizing submission of the first trading order and the second trading order to the trading exchange for simultaneous fulfillment by the trading exchange.