3

I am new to the FIX protocol and I am using QuickFIX to parse my FIX messages. Whenever I receive a Position Report message (AP), it gets rejected by the FIX engine with the below error:

Group 702's first entry does not start with delimiter 704

Here 702 is a group tag. I did some research and found that a repeating group message uses its first field as a delimiter. In my case group 702 is supposed to have either tag 704 (LongQty) or 705 (ShortQty). Only one of either tags will be present.

My counterparty is not sending the 703 tag. When the FIX engine sees there is no 704 tag in some cases, it rejects the message. Please let me know your suggestion to over come this problem.

TT.
  • 15,774
  • 6
  • 47
  • 88
Vivek Jeeva Kumar
  • 75
  • 2
  • 11

1 Answers1

2

FIX expects every group to start with a single consistent tag.

You can alter that tag in your XML DataDictionary, for instance, to use 704 instead of 703, by rearranging (or deleting/adding) the fields in that group.

In my case group 702 is supposed to have either tag 704(LongQty) or 705(ShortQty).

No, that won't work. Does it always start with 704 or does it always start with 705? It can't be one-of-either.

If your counterparty really is saying that it's one-of-either, then they are doing FIX wrong and we should publicly shame them. (Seriously, can't they just put 704=0 instead of omitting it?) To deal with this idiocy, you may have to hack the QF engine.

I suggest you double-check with your counterparty to confirm that they really are doing it wrong like this. I'm hoping (for your sake) that you are mistaken.

EDIT:

This is from the FIX 44 spec, Vol 1, page 19:

If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry. The first field listed after the NoXXX, then becomes conditionally required if the NoXXX field is greater than zero.

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
  • I double checked with my data dictionary, my counterparty is expecting either of the two tags. please look at the below message _20161004-18:20:15.063 : 8=FIX.4.49=23735=AP34=549=XXXX52=20161004-18:20:14.83556=XXXDEMOFIX1=9277455=GBPUSD231=1581=1702=1705=27200710=XXXX715=20161004721=981a4eec-1886-4571-bd25-cf3c9e10115a728=0730=1.27940472230385731=1734=1.2794047223038510=198_ – Vivek Jeeva Kumar Oct 05 '16 at 19:47
  • You mean the counterparty is *sending* (not ~expecting~) either of the two tags, right? You are the receiver. – Grant Birchmeier Oct 05 '16 at 20:24
  • Yes. That's right. Is there any way to over come this. – Vivek Jeeva Kumar Oct 05 '16 at 20:27
  • Unfortunately, no. You'll have to hack the engine. You should also inform them that they are using FIX wrong; maybe they'll decide to fix it. Looks like this is spelled out in FIX protocol spec volume 1; you should find the passage (it's not a hard spec to read) in the spec for the relevant FIX version (4.4, 5.0, whatever) and pass it on to your counterparty. – Grant Birchmeier Oct 05 '16 at 20:30
  • I'm probably mistaken, but I'm seeing in the message the OP posted in comment 702 followed by 705. 703 is conditionally required if 702>1 (which it is not). Then either 704 or 705 should follow (they are both marked optional in [the definition I'm seeing](http://www.onixs.biz/fix-dictionary/4.4/compBlock_PositionQty.html)) – TT. Oct 05 '16 at 23:22
  • 1
    @TT - That conditionally-required annotation for 703 is in conflict with the general FIX-spec requirement that groups must start with a consistent delimiter. I can only assume that the 703 annotation must be an error. If I was implementing the standard FIX DD, I would treat 703 as required. – Grant Birchmeier Oct 06 '16 at 14:49
  • @TT - See spec excerpt I added to my answer above. – Grant Birchmeier Oct 06 '16 at 14:54
  • 2
    I generally get the impression that Vivek's counterparty might be somewhat new to FIX, and is using a custom-created solution rather than a proven engine. Lacking experience in FIX and existing engines, they don't realize that repeating groups can be a minefield, and have unknowingly diverted from best practice. – Grant Birchmeier Oct 06 '16 at 14:57