Imported from previous forum
Are there any integration documents which blueprint multi-leg Options/Futures products within the ATDL file?
Hi Liselle,
The specification offers partial support for some multi-legged strategies. But there are no useful examples to show how to write the atdl code.
The big problem is that the E/OMS implementation of multi-legged orders has wide variances from vendor to vendor. It has been quite a challenge to get atdl to support some of the use cases.
Also I’m not aware of any E/OMS which support atdl-sourced mutli-legged orders. (Please let me know if there are.)
If you are willing to submit an example (in word format) of one of your strategies to the WG it would help us understand the requirements better. And maybe we can support some if the use-cases.
-Greg
Hi Liselle,
Just wanted to expand on Greg’s response.
During the development of FIXatdl we spent quite a bit of time looking at trading two asset types off a single order ticket (FIXatld screen).
The one solid use-case we had at that time involved cash treasury bonds and a exchange traded interest rate future. The idea was to trade the interest rate future in one direction, and simultaneously, in the opposite direction trade multiple cash treasury bonds, each spread out in a duration ladder, to closely match that future. Trader needed to see each bond listed separately on the order screen(s), and also the interest rate future. It was an integrated order.
There was some question around how we were going to handle the possibility of not knowing how many bonds would be involved in the trade up front. So the UI would need to be able to keep building an arbitrary number or rows for the bond portion of the trade, until the trader indicated all the bond trades were in, no more.
To the best of my knowledge that use-case we worked with has not yet been implemented in FIXatdl in a commercial system.
Virtually all the Sell Side participants in the FIXatdl standard, at the time of its development, had separate “desks” for each asset type (equities, FI, options, futures, FX). No major Sell-Side firm wanted a single FIX message headed their way that had to be broken down on their end, and routed across separate execution “desks” with additional coordination built on top. The above use-case was the only real exception we had to work from.
Equity Pairs trading was close, and that was a well understood use-case. Here two separate stocks are traded from a single order screen (one long and the other short). Trading of each stock can be “algorithmic” but on top of that, execution of one side needs to be aware and coordinated with execution of the other. Subsequent to development we have seen FIXatdl pairs trade commercially. The UI’s executed in FIXatdl have been quite rich, enabling a trader to specify in significant detail how each side is to trade, and how balanced the execution must always remain, from one side to the next.
For a bit more overview, here roughly are the order types the WG initially envisioned leaving a FIXatdl enabled system:
Category - SingleGeneralOrderHandling
D NewOrderSingle
G OrderCancelReplaceRequest
Category - MultilegOrders
AB NewOrderMultileg
AC MultilegOrderCancelReplace
Category - ProgramTrading
E NewOrderList
K ListCancelRequest
L ListExecute
What we found however, for 99% of usage out there, it was plain vanilla NewOrderSingle messaging (and the related OrderCancelReplaceRequest).
There was not much draw at all for creating a flexible UI that resulted in a NewOrderMultileg and even less for a NewOrderList.
We even had a heck of a time finding people who actually used those more advanced FIX message types. Each has a large number of options. We pleaded for users of those message types to give us some actual samples we could work back from. That way we could insure FIXatdl would meet their needs.
I assume those message types are in use someplace, since it’s clear plenty of effort went into their creation. Perhaps the usage so far has not required a frequently updated trader UI? Or, the usage is so esoteric that its pretty much “one-offs” from party to party with little need for “standards”? I must admit it somewhat puzzles me.
FIXatdl was however constructed with a substantial amount of flexibility. It certainly can draw any single option, future or FX order screen with great ease, and it offers some very very nice features for doing just exactly that, and very easily. However we have not seen much pick up to date on those asset types. Equity algos have been the red hot commercial area to date for FIXatdl.
If you had traders using FIXatdl front ends to trade options and futures, the “leap” to putting both on the same FIXatdl screen as a NewOrderMultileg would not be hard (provided of course you can receive that integrated message and separate out it’s individual components and route them to the correct execution “desks”.)
For that matter FIXatdl would likely work very nicely on single issuer credit default swaps - a relatively new “standardized” product that would go very well with cash bonds on a multileg.
Want to encourage you to think up a good use-case that is close to what you actually want to accomplish.
Remember this is all public so be careful with your firm’s proprietary plans if they are sensitive. Its pretty easy to mask everything as all our WG needs really is the UI design and data structures. Exact parameter names and UI labels are not needed by the WG.
We may have some ideas on how you might proceed.
I’m also thinking your equity pairs algo people might be good to tap into for thinking about how, you on your end, will be “doing two things at once”, (plus perhaps crossing traditionally isolated desks) and still keeping it all in check.
Rick
Hello,
I hate to resurrect this old thread, but does anyone have any example ATDL files for use with NewOrderMultileg? I am using ATDL4NET to try and validate my ATDL files, but I’m not sure they’re handling the multileg case and repeating group parameters correctly. I have my groups of leg parameters nested inside of a RepeatingGroup, but the associated controls do not “see” these parameters and the validator crashes. Once I move the Parameters outside of the RepeatingGroup block, everything runs fine.
Do fields and controls associated with the repeating group portion of a NewOrderMultileg need to have certain attributes or tags, or does this seem to be a shortcoming of ATDL4NET?
The short answer is: use “flocked” newOrderSingle messages. By flocked I mean separate orders for each leg, with each order containing a unique flock identifier. Just tack the central parameters (those that pertain to the entire flock) on to your lead bird, and include a “end of flock” parameter on the last one.
Decide if you want the OMS/EMS to batch them together and launch all in rapid succession only when all are ready, or if you want them going out one by one, with the BD in charge of coordinating the “flock” level interactions, when to start execution on each bird in the flock, etc.
In the flock scenario FIXatdl FLOW and final VALIDATION rules will only work correctly on each separate order, as the FIXatdl rules system was never intended to extend across multiple orders. Still, the advantages of newOrderSingles are hard to beat. They are well understood and largely standardized on both sides of the FIX wire. You are building on a firm mutual foundation.
Cancel / replace is also much simpler with a flock of newOrderSingles. All that interaction is well understood.
On the Sell Side (party making the algo execute) its quick and easy to take apart a flock and route simple orders to separate markets (stocks, bonds, futures, options, fx, etc.). Each bird in the flock is complete for its market, ready to go downstream without re drafting it.
The underlying newOrderMultileg message is esoteric to be sure. The few who have actually deployed it (over decades) have done so in highly unique ways. Its very party to party specific (so it requires specific one-off on-boarding and testing.) FIXatdl can’t magically layer on top and make all this straightforward.
It doesn’t surprise me that the open source FIXatdl parser renders “choke up” when trying to write some newOrderMultileg messages. Past a pair and anything cross asset can get complex quickly.
That being said, if you need to go under the hood with ATDL4net you likely need to talk to Steve Wilkinson now at https://huskyfinance.com/team. Back when FIXatdl v1.1 was shipped he was very active writing that specific windows parcer. (cornerstonetechnology.com & atdl4net.org [no longer active websites] ) Steve was a great guy and VERY helpful to the FIXatdl WG. As you know its one thing to write a schema and its another to write code that processes any conforming XML to that schema. Steve found numerous things in our FIXatdl draft that were loose, helped improve things, test things, improve wording and documentation. He was deep in the code and understood FIXatdl (including its limits) very well back then.
Summary:
NewOrderMultileg (shaky foundation for sure!), FIXatdl WG / standard (very interested in list, multi leg and cross asset trades - but never could build a large quorum of actual users to totally flesh out a full, highly compatible set of FIXatdl features to support those message types in all their potential complexity. “Think regression testing…”
Challenge is to find 10 distinct multi leg message traders with available time and a sense of FIX community. Each brings 10 of their most common multi leg order message samples that illustrate how they have implemented newOrderMultileg (all those can be disguised so no firm proprietary information leaks out - all the WG really ever cared about are the data types and interactions, not data labels that might provide clues to the algo’s logic or strategy).
IMHO …not going to happen.
…newOrderSingle…newOrderSingle…newOrderSingle All so simple! lol
Rick
1 Like
@rick.labs I get your point about which FIX messages are fit for purpose versus actual implementations, but any new development should consider using MassOrder (MsgType DJ) message. It allows multiple orders to be entered, canceled, or modified with a single message.
Rick,
Thank you very much for the info. Understood re: your points about the NewOrderMultileg message type… it’s certainly not easy to deal with haha.
I wanted to point out that NewOrderMultileg(35=AB) and MassOrder(35=DJ) have different purposes, i.e. the latter is not a new version of the former. MassOrder(35=DJ) is about unrelated orders being handled by means of a single message, i.e. they can be executed independently of one another. Individual orders of a MassOrder(35=DJ) message can have different instruments. NewOrderMultileg(35=AB) should be used for multi leg instruments orders where all legs are traded atomically at the same time.
Using NewOrderSingle(35=D) to emulate NewOrderMultileg(35=AB) is probably when repeating groups are not supported by one or both counterparties.