Patent Application
20140249979
The present invention relates to the ordering and handling of electronic financial services messages destined for an exchange or other trading venue.
Ever since the Rothschilds allegedly used carrier pigeons to trade on the outcome of the Battle of Waterloo, there has been a drive to increase the speed of one's financial trades to gain a competitive edge in the financial services industry. Until high speed servers came into existence in the late 20th century, orders were transmitted over the telephone and received over a telegraphic stock ticker. Now, high speed servers transmit electronic orders both wirelessly and over fibre-optic cables near the speed of light, with servers being physically located as near to financial exchanges as possible in order to decrease the time delay, or latency, between an order's transmission and execution.
Efforts to improve the speed at which a trade occurs have also focused on optimizing network system designs. Currently, speeds can be increased through real-time latency monitoring and ensuring that trading traffic is always on a path with minimum latency, for latency optimized systems. Systems can also be designed to optimize throughput, however present art systems are fixed at design time to be either latency optimized or throughput optimized with respect to message handling and can not automatically switch between the two. For a given processing power, a specific message in a latency optimized system will take less time to process, but a lower rate of messages can be handled when compared to a throughput optimized system, where a specific message will take longer to pass through but more messages can be handled. Current typical real world latencies are on the order of 20-100 microseconds; however some consider anything over 5 microseconds to be too long.
It would be useful to further enhance the speed at which time critical events, such as trades, occur by providing a system and method for improving the speed with which individual electronic messages are handled.
It would also be useful to obtain the benefits of both throughput-optimized and latency-optimized systems.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.
The present invention provides a system that employs several processes for enhancing the handling speed of electronic financial services messages coming into and out of a financial service provider so that messages are handled as efficiently as possible.
A fast-path slow-path risk checker process is employed on incoming messages to a financial services center. Messages containing orders intended for an exchange or other trading venue, including commodities, currency, derivative, fixed income, and stock exchanges pass through a financial services data center and are handled on a fast-path basis while those messages coming into the financial services center such as updates from an exchange or updates going out to a trader occur on a slower path.
The speed at which incoming messages containing fast-path designated orders are handled is further enhanced by a message parsing process which parses individual incoming messages in a manner that extracts information needed for time critical computations from state update information that can be handled on a longer timeframe.
The system also employs a dual process for optimizing in real-time the balancing of throughput versus latency for electronic message handling. The system allows for the automatic switching between the two optimized pathways based on either user defined or independently defined preferences.
In accordance with the present invention, electronic financial services messages, such as order entry messages destined for an exchange or other trading venue, are handled in a manner that separates time-critical information that requires computations that must happen extremely fast from state updates that can happen on a longer timeframe.
Further in accordance with the present invention, a system and method are disclosed for analyzing the extracted time-critical information in order to optimize the real time information traffic flow and automatically switch on the fly between a throughput-optimized and a latency-optimized system for electronic message handling.
Still further in accordance with the present invention, a system and method are disclosed for optimizing real-time balancing of throughput versus latency of traffic flow for electronic message handling based on either user controlled or independently controlled settings and preferences.
Disclosed are one or more non-transitory computer readable media comprising computer readable instructions which, when processed by one or more processors cause said processors to: receive a financial service message comprising first data and second data; parse the message to extract the first data; check the first data against one or more parameters in a memory; transmit the first data along a first path to an exchange if the check is successful; and transmit the second data to the memory along a second path slower than the first path.
Also disclosed is a system for processing financial service messages comprising: a memory and one or more processors connected thereto, the processors configured to: receive a financial service message comprising first data and second data; parse the message to extract the first data; check the first data against one or more parameters in the memory; transmit the first data along a first path to an exchange if the check is successful; and transmit the second data to the memory along a second path slower than the first path.
Further disclosed is a method for processing financial service messages comprising the steps of: receiving, by a processor, a financial service message comprising first data and second data; parsing, by the processor, the message to extract the first data; checking, by the processor, the first data against one or more parameters in a memory; transmitting, by the processor, the first data along a first path to an exchange if the check is successful; and transmitting, by the processor, the second data to the memory along a second path slower than the first path.
These and other features and advantages of the invention will be apparent from the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing summary and the following detailed description are explanatory only and should not be construed as restricting the scope of the invention as claimed.
It is desirable to reduce the time it takes in handling individual messages coming in from traders, including any necessary pre-trade risk checks. The electronic messages coming in can be in any electronic message format. The Financial Information eXchange (FIX) Protocol format which is an industry standard protocol is often used by many traders and a number of exchanges. However the invention is applicable to any electronic message protocol format used by traders, applications and exchanges including but not limited to Extensible Markup Language (XML), Financial Information eXchange Markup Language (FIXML), OUCH, POUCH and RASHport protocol standards.
The core content of an incoming message includes information such as Account, (who is placing the trade); Price (the price at which the trade is being made); Symbol (the “name” of the asset being traded); and Size (the number of shares to be traded).
Risk checks are performed to measure the “riskiness” of a message just received; and as these checks must be performed, they are often perceived as a regulatory “time tax”. To minimize the impact of these regulatory computations, it is already accepted practice to treat the computational results as approximations, rather than precise answers. This allows the process to ignore the asynchronous nature of a communication between, for example, a trader and an exchange. The specific implementation for this is a risk check gateway, which must accept or reject messages based on their content, and relative to state information derived from previous messages.
Examples of some computations that must happen extremely fast include such housekeeping chores as looking up the symbol to see if it is a tradable object, as well as looking up the account to see if it is authorized to trade. Determination of authorization to trade may include such things as whether or not the order is too large (Size>some threshold); and whether or not the value of the order is too large (Size*Price>some threshold). Authorization to trade may also include whether the particular account is making too many trades (Sum of all Size*Price for that account>some threshold) or trading too fast (Number of Orders in specified timeframe>some threshold).
The state update portions of an incoming message are those updates that do not have a time critical component to them. Some examples of state updates that do not need to occur as quickly include things like adding an incoming trade to the list of previous trades, and updating the current value of all trades for the account with the value of the incoming trade. Other state updates may include updating the “timing” information to keep track of how fast orders are coming in.
As illustrated in
At an exchange 60, generally incoming trade requests are queued up in the order they arrive. So the quicker messages can pass through FMP 10 the sooner they can get into the queue at an exchange 60. In addition, when a sequence of orders is being sent, the quicker they can be processed, the more likely they will arrive at the exchange 60 as a block of messages without any interspersed orders from competitors.
Messages coming in from a trader 50 are “requests” on an exchange 60. Messages coming from an exchange 60 are responses to the request. Two distinct data paths exist in the FMP 10, one for messages originating from a trader 50, and the other for messages originating from an exchange 60. There exists shared memory and data structures 22 between the two data paths. This shared memory and the data structures 22 hold data that is stored in a known way; for example as files, databases and directories. The shared memory and data structures 22 are embodied in one or more memories and are accessible to both paths. The shared memory and data structures 22 are read-only to messages coming in from a trader 50, and read-write for messages coming in from an exchange 60.
The shared memory and data structures 22 record and store information related to the current state and history of each account. For example, an individual “account” record within the structure would store information such as a list of all outstanding trades executed since the account was started; a list of all executed trades since the account was started; the value of all executed and/or outstanding trades, arranged by symbol; and an aggregate value of all trading, summed across all traded symbols for that account.
Each account record has components which are updated from an incoming trade request message and are of the “outstanding trade” category. Account record components updated from messages coming from an exchange 60 are both of the “outstanding” variety (for example, a request to delete/undo an outstanding trade after a trade is accepted, representing a confirmation to execute it) or of the “executed” variety (values are moved from an outstanding state to an executed state once confirmation that a trade has actually taken place is received from an exchange 60, the trade having been fulfilled in part or in full).
The fast-path and slow-path have independent message queues. The fast-path message queue 12 allows the fast-path to function as fast as possible during periods of high message traffic. The slow-path queue 14 can buffer its own messages and process them over an extended period of time. The fast-path queue 12 has one input and is located directly between the fast-path message ingress 2 to the FMP 10 and the compute engine 24. The slow-path queue 14 has two inputs, these being update data 13 (of the “outstanding” variety) from an incoming trade as the message is being processed by the compute engine 24 and update data 15 (of the “outstanding” and “executed” variety) incoming from an exchange 60.
As illustrated in
A second local memory store 20 contains independent and/or user defined preferences and settings which can be in the form of configuration, limit and/or threshold settings which can be set by an independent application or user. These settings are stored in a separate data structure, second local memory store 20, which is separate from the earlier referenced shared memory and data structures 22.
The compute engine 24 then combines the information from the message with the information from the shared memory and data structures 22 and second local memory store 20. If the result of the computation is acceptable, the necessary portion of the message is immediately forwarded out of the FMP 10 along fast-path message egress 4 to an exchange 60 server where the request is executed. Note that the form of the message may change as computation checks are performed and the trade request message is converted into an order sent on to the exchange.
There are two steps to determining if the result of a computation is acceptable and therefore able to be immediately forwarded out to an exchange 60. The first step is a set of checks which are selected from an available pool of checks; the default being that all checks are active. This first step is generally an activity performed at the start-up of a user's trading account, although the checks can also be actively managed in near real time. The incoming message must pass all of the checks. If the incoming message fails any activated check, the message is not forwarded to the exchange. In the case of an unforwarded message, a notification may be sent to the shared memory and data structures 22 storing the data of the user's account and then notification may also be sent to trader 50 along slow-path message egress 8 as a user update 40.
The compute engine 24 may also update the local shared memory and data structures 22 by enqueueing update data 13 to queue 14 along the slow-path. Generally this type of data would be Account ID, Symbol, Size of order, and Price information extracted from the incoming message; along with some calculated values, such as “Value=Size*Price” computed by the fast-path.
Also shown in
An update engine 28 combines the extracted information from the message coming in from the exchange 60 with information in the local shared memory and data structures 22, and then updates the shared memory and data structures 22 based on the result. These updates are shown in
As described earlier, examples of such an update may include the status of the trade (i.e. whether the trade was rejected, accepted, executed) and the update engine 28 will update the status of an order such as “total value executed” and “total value outstanding”. In the case of a successful trade execution, the “total value executed” would be increased and the “total value outstanding” would be decreased by the same amount. If the trade was executed in its entirety, the specific data structure holding the “outstanding” value or record can then be optionally deleted, as it is no longer needed; or it can just be updated showing the trade being executed in its entirety.
It may be noted that two closely-spaced messages from a trader 50 could result in the second message clearing the fast-path before the slow-path can update the account status. However this is considered an acceptable practice, as the checks are in a category of “close enough” and the second message may be processed before a response from the first message is received from the exchange 60.
Another aspect of the invention to improve the speed with which electronic financial services messages are handled is through the real-time balancing of electronic message flow in a way that optimizes latency and throughput based on the traffic flow. Because FIX messages are an industry standard protocol and often used by many traders 50 and a number of exchanges 60, the invention is described in greater detail with reference to the handling of this type of electronic message. However the system is applicable to any electronic message protocol format used by traders, applications and exchanges including but not limited to Extensible Markup Language (XML), Financial Information eXchange Markup Language (FIXML), OUCH, POUCH and RASHport protocol standards. A translator engine can be employed for translating electronic messages coming into the FMP 10 in one order protocol format that need to egress to an application, exchange 60 or trader 50 in another protocol format.
Within the system design of the invention, there is a real-time balancing of FIX (or other preferred protocol format) message flow that optimizes latency and throughput based on the traffic flow into the system. Switching between a latency optimized flow and a throughput optimized flow can occur automatically and independent of user control, or if desired, can occur taking into account user preferences and settings.
A primary criteria for switching between the two optimization methods is the order rate. For example, if messages are arriving faster than X/millisecond, the system uses a throughput-optimized configuration shown as processing Path “A” along the top half of
As shown in
Each message must undergo a series of calculations, based on the content of the message. The end result of the calculations results in two transformations; 1) a signal notifying the user or downstream process of the result and 2) modification of the message content based on the computational result.
As shown in
Messages are denoted in
Parsing of the individual messages occurs independent of the processing path before entering the ingress queue manager 12. In the case of a multi-pipeline design as illustrated in
The second path to processing a message, as shown in
In an alternate embodiment, a split step can be implemented to split the calculations (C1, C2, C3) into separate paths so that one message can be being split while the preceding message is undergoing calculation. However depending on the hardware used, splitting the individual messages can introduce a touch more latency than treating it as a monolithic block.
When traffic builds up in the parallel approach of Path B, even though any given message is processed very quickly, the fact that it has to sit in a queue waiting its turn for processing means that the message is not, in fact, handled in a “timely manner”. The key is to implement both approaches. A traffic flow “gauge” 32 measures traffic flow (by any number of suitable methods known in the art), and based on that flow, the ingress queue manager 12 decides which approach (or process) should be utilized. The ingress queue manager 12 also has methods for ensuring that switchover between the two processes occurs without loss of messages, and without re-ordering of messages at the output end.
To prevent re-ordering, the input or ingress queue manager 12 is organized on a first-in first-out (FIFO) basis, so messages are guaranteed to be pulled from the queue in the correct order. When a switchover condition is encountered, it will momentarily stop pulling messages from the queue until it has received a signal that the current path has finished processing messages already in flight.
In a system utilizing the dual processes as described, typical processing time differentials between parallel processed messages compared to pipeline or serially processed messages may range from approximately 4× to 8× faster for the parallel processed messages being handled. For example, there may be a 1 microsecond duration required for the parallel processing of a message during low traffic flow, versus a 4 microsecond duration required when pipeline processing the message during high traffic flow. Of course the speeds can vary depending on exactly what computations are needing to be done. So long as there is a significant difference in the processing times between the two paths, then the system is generally worth implementing. A minimum difference may, for example only, be a factor of about three between the speeds of each path.
The goal is to have “zero latency” during normal traffic, and “really low” latency during heavy traffic. For the current state of the art, really low latency would be anything under 3-4 microseconds and may also be referred to as “ultra low latency”.
A logic flow diagram for the processing and selecting of message paths for incoming messages is illustrated in
Once the message segments are directed to step 80, for throughput optimized processing, the message segments are directed down a pipeline processing path where they are processed serially through computational checks (“C1”, “C2”, “C3”, “C4”) in step 82. If the message segments pass all active computational checks at step 84 then the message becomes an order (step 86) in descheduler 37 and is forwarded onto an egress queue manager 42 (step 100) which forwards the order on to a designated exchange (step 102). If the message segments do not pass all active computational checks at step 84 then the message is kicked out of line and sent down a slower processing path (step 106).
Going back to step 78 in
An example of a networked environment is illustrated in
The financial services data center 120 illustrated in
It is understood by one skilled in the art that the communication functionality may also be part of the same hardware as the data processing and update processing functionality of the system, and the memory and data storage may be separate compartmentalized areas of a single shared component or separate networked components (internal and external to) data center 120.
It should also be noted that specific timescales given herein are only guidelines. What are now considered particular working timescales will likely fall in the future as technology improves. However, it is expected that the system will still be able to provide the benefit of optimizing latency or throughput depending on the incoming message rate.
The foregoing embodiments of the invention are examples and can be varied in many ways. Such present or future variations are not to be regarded as a departure from the scope of the invention, and all such modifications as are obvious to one skilled in the art are intended to be included within the scope of the following claims.
