Imported from previous forum
Hi,
I need a generic FIX specification to hand to our customers and then map this generic fix spec to various other fix specifications which seem to differ on a broker by broker basis (i.e Some use 6000 series tags, some use 5000 series etc)
I think I should use Tag 847 with 848 containing all the strategy parameters, and use this across all Fix versions 4.0 - 4.4 (actually using 5000 series tags such as 5847 where necessary). However, should I be using the repeating 957-960 groups for Fix v4.4+ ?? Seems like not all Fix engines support repeating groups of tags. This would potentially mean having two Fix formats I need to specify, map, and support. We are not using FIXML.
Any suggestions would be most helpful, many thanks
Lee
I like the 957+ tags, they seem a good implementation to me, but I see very few people so far using FIX 5.0
Hi,
I need a generic FIX specification to hand to our customers and then map
this generic fix spec to various other fix specifications which seem to
differ on a broker by broker basis (i.e Some use 6000 series tags, some
use 5000 series etc)I think I should use Tag 847 with 848 containing all the strategy
parameters, and use this across all Fix versions 4.0 - 4.4 (actually
using 5000 series tags such as 5847 where necessary). However, should I
be using the repeating 957-960 groups for Fix v4.4+ ?? Seems like not
all Fix engines support repeating groups of tags. This would potentially
mean having two Fix formats I need to specify, map, and support. We are
not using FIXML.Any suggestions would be most helpful, many thanks
Lee
Hi Lee,
You point up one of the inherent difficulties in FIX – the standards are formed by committees, over time, and not everything is fully specified. There is large variation in how people actually apply the standards, and when they support new versions of the standard.
The new aglo standard - FIXatdl (now in beta expected to got to the GTC for final approval this quarter) will support doing custom algo parameters any way you want (repeating groups, unique tags, etc).
We specifically avoided mandating the use of repeating groups despite the fact they are clearly the most elegant technical solution. While I’m far removed from all the FIX hubs, routing networks and other “plumbing” issues, I’m aware that there are plenty of nodes in the overall FIX cloud, as it now stands, where newer versions of FIX are not supported. I’ve also seen situations where FIX messages went in various execution management systems, were totally taken apart, internal operations were performed using a proprietary messaging structure, actions were taken, and then standard FIX messages were reconstructed for output. Some of those systems do not support the later FIX standards and they are slow to update.
So, what to do? Support repeating groups on your end (and everything 4.4+ though 5+…) is a great idea and well worth the incremental effort, but also support all 4.0+ solutions too for maximum “today” connectivity.
You can also look at how 15 firms are doing examples in:
http://www.fixprotocol.org/working_groups/algowg/documents (register for free at http://www.fixprotocol.org/register, log in and return to that directory if necessary to see the files).
Not a simple answer, but you will find in the long run supporting both older and newer FIX algo parameter expressions, right from the outset will probably be the lowest cost, best long-term solution.
Rick
Hi
In the end I settled on the simplest strategy, tag 847 (or 5847) contains the type of Strategy. Tag 848 (or 5848) contains a String of repeating Strategies:
Strategy parameter example:
TargetStrategy(847)=VWAP
NoStrategyParameters(957)=2 StrategyParameterName(958)=ExecutionStyle
StrategyParameterType(959)=1 (Integer) StrategyParameterValue(960)=3 (Medium)
StrategyParameterName(958)=ScheduleDeviation
StrategyParameterType(959)=1(Integer), StrategyParameterValue(960)=0 (None)
Becomes the following FIX:
847=1
848=957:2;958:ExecutionStyle;959:1;960:3;958:ScheduleDeviation;959:1;960:0
Easy to add new strategies, and easy to extract them and map them to various brokers Custom tag implementations.
Thanks
Lee