[This message was posted by Richard Labs of CL&B Capital Management, LLC
<[EMAIL PROTECTED]> to the "Algorithmic Trading" discussion forum at
http://fixprotocol.org/discuss/31. You can reply to it on-line at
http://fixprotocol.org/discuss/read/fc207ebf - PLEASE DO NOT REPLY BY MAIL.]
Yesterday at the regular weekly FIXatdl WG technical meeting we reviewed a
small but important enhancement geared to pre trade analytics. More details
below.
If you have comments, or ideas, by all means now is the time to voice them.
Thanks!
Rick
Pre Order Feedback
Jim A. presented a compelling use-case and proposed simple solution to handle
pre order information flow
Overview Use-Case
Trader is in the process of building an algo order. Some or all of the
parameters have been entered. Trader needs a way to send those preliminary
strategy specific parameter-value pairs to the broker dealer. The broker dealer
then can send back text, perhaps the results of some calculations as text, and
very short message strings. This return trip text is for read-only purposes by
the trader, to be merely viewed directly on the face of the “order ticket”.
Example - trader selects a strategy and enters the security, side and
quantity, plus a few other algo parameters. This preliminary info is sent to
the BD, "out of band" - meaning not through the traditional FIX pipes and
infrastructure. BD calculates “if the proposed algo trade, as specified was
live in the market at this time, it would achieve its fill by moving the market
price away from the current midpoint of the national best bid and offer, by –4%
on the entire order quantity of 25000 shares (on average), with expected price
“recovery” by the market to –2% down from here, by the time the market close.
With aggressiveness set at medium-high the order for 50,000 shares would fill
in an estimated 35 minutes. This block would therefore be down 2% further that
where the stock was estimated to close, were the broad market to remain flat
for the rest of the day... That entire message would not likely be returned,
only the calculated values as text and labels.
Existing facility
Currently in FIXatdl there is the facility to send a draft order to a BD, and
later pick up that specific order at the BD’s web servers, via a specifically
formatted HTTP request that contains the client ID and client order ID. This is
designed for pre trade “dialog” about that draft order over SSL and enables the
use of rich media (intense graphics, video, audio, etc.) At the conclusion of
that dialog there is a mechanism by which an order “draft” may be expressed and
imported back into the OMS, complete with all parameter values populated, all
ready for the OMS to validate the import, and if that validation is passed,
present that order to the human trader in the FIXatdl driven order screen. The
trader may then make any final revisions through the OMS, subject to the OMS’s
oversight, and ultimately hit the send order button, which causes the order to
be send out in standard FIX tag=value format, over the dedicated and standing
FIX infrastructure. (In-band). This facility is
well suited for educational purposes and various non time pressured pretrade
analytics, and may contain a variety of web interactions targeted at educating
traders about the nuances using any particular strategy or even choosing
between strategies. Note: draft order always expire and are never returned to
live status. So changing strategies from a draft poses absolutely no problems.
There is also a similar facility already built into FIXatdl to link to a live
order that has been released to execution. This enables receipt of all types of
in-process analytics, dashboards, cancel/replace suggestions, and post-trade
analytics.
Need for New Facility
The downside to the above draft order/html web browser facility relates
directly to the needs of active, high volume traders, who are experienced with
specific algo strategies they are currently deploying. This group already
“knows what they want”, and they often need to create a bevy of orders quickly,
one after another. This audience often trades in a highly stressed environment,
and as certain market events occur, the stress level increases, and the ability
to rapidly complete and issue algo orders becomes exceedingly important.
The draft order/html web browser facility requires the launch of a browser, and
the resulting browser window may be randomly placed on the display, far removed
visually from the specific “order ticket” the trader is currently locked focus
on, trying to finalize it, and get it off the desktop and working in the
markets. While the browser based window facility offers wide capability in
terms of multimedia, rich graphics, and maximum flexibility, those features
come with a latency cost and rendering overhead, along with the cognitive
complexity of needing to visually shift between two different windows dealing
with the same subject, screen flicker, distracting motion on the display,
covering up other screen real estate that may need to be continuously attended
to, etc.
Overview description of the proposed Pre-Order Feedback Facility, and
preliminary features list
A second button would be added to order entry screens on ordering systems
supporting this feature, most likely near the “send order” button. This second
button would be labeled “Pre Order Feedback” or perhaps just “Feedback”. When
pressed, all that would happen is a HTTP request string would exit the OMS over
the Internet, containing all order parameters that were “known at that time”
(had values entered), plus a few other standard FIX fields, in a standardized
string. The prefix URL of that HTTP request would be included in the FIXatdl
xml file according to the schema, and the remaining format of the HTTP request
would be standardized according to FIXatdl documentation. In essence this is
just a very basic dump of the order parameters, known at that time, out to a
URL specified by the BD.
The return response from the web application server would be simple text,
broken into named fields and values, for display back to the trader in near
real time. All of this response would be read only, with zero facility anywhere
to automatically alter an order parameter value.
The BD would have the facility in the schema to suggest the placement of read
only widgets (typically just labels) on the screens that would accept the
values returned by the above HTTP request/response cycle. Currently the
thinking is this facility would be described in an additional simple schema
(like layout, flow and validation) that would be optional. In this schema the
return fields would be named, and only widgets contained in the standard widget
library could be placed on the suggested GUI layouts. Placement capability
would be identical to how the parameter widgets are currently positioned. If
the feature were implemented, the OMS would merely place the widgets on the
screens and be responsible for filing their values with the text that was
returned from the HTTP requests.
Recap
* Entire facility is optional
* Existing schema structure is unaffected
* Gives a high-speed way to communicate very brief calculated values (as
text results) and very short messages back to traders in nearly real time
* Very light weight - only text is supported, no values, no data types, no
graphics
* The facility is designed so the trader may repeatedly hit the “Pre Order
Feedback” button and get updated “near” real- time feedback without clogging
the live FIX order pipes
* Feedback results may be visually placed adjacent to a specific parameter.
That should allow feedback text to be very closely positioned adjacent to
parameters that are sensitive and may require adjustment. A suggested
replacement value might be displayed as text.
* None of the response text could automatically initialize or alter any
parameter value. It all human "read only".
* Nothing in this facility delays or impairs FIX order placement if
Internet connections are delayed or unavailable. Timely response is never
guaranteed.
* Screen building / rendering remains fully subject to automation. The
display-only “response” widgets (most likely just labels) are limited to those
contained in the FIXatdl Widget Library, already well known to the parsers and
OMS.
* In addition to a human trader hitting the “Pre Order Feedback” button
events raised in the FLOW and/or Validation area (e.g. validation failed) might
also be used to trigger the send/report cycle. Example, aggressiveness slider
1-10 (low to high), when set to above 8 – a FLOW rule fires - “Request
Feedback”. Spit out the parameters entered thus far, get a response, display
those to the trader”. Might result in something like “50k shares of xyz is >
50% daily volume. Aggressiveness > 8 expected to move price > 15%.”
Request for any additional feedback
Mindful of the intense pressure the WG is under to to ship FIXatdl v1.1 in
final form, and to avoid “feature creep”, particularly introduced at the 11th
hour, the WG today unanimously agreed that the above new facility may indeed be
highly beneficial, and agreed to work briskly towards a more comprehensive
specification for possible inclusion in v1.1. The use-case presented was deemed
to be highly representative of a large end user need and therefore a high
priority. The risk to the development schedule appears slight. Furthermore, the
impact on the standing investment in FIXatdl parsing code base was also
initially estimated to quite low.
We are looking for any feedback, including specific implementation ideas, or
potential conflicts regarding the proposed new quick (but not guaranteed)
feedback facility.
[You can unsubscribe from this discussion group by sending a message to
mailto:[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
