{{Quickfixn}} a question about ClOrdID in Allocation Messages not matching the value used in New Order Single Messages

Grant Birchmeier gbirchmeier at connamara.com
Wed May 30 09:34:35 PDT 2018


The FIX data dictionary is at best considered a suggestion.

The reality is that counterparties do whatever they what: adding fields,
removing fields, *misusing* fields even.

There isn't much point in asking what the "proper" FIX way is, because
honestly, there isn't one.

So yeah, in the FIX world, not making sense is normal.  Go with what your
counterparty wants and continue with your day :)

On Wed, May 30, 2018 at 11:26 AM, Mark Cooke <mc.developer at verizon.net>
wrote:

> For some years now, our application has been using a values for ClOrdID
> when sending Allocation Messages, which does not match the value used in
> our New Order Single Messages. Though, they are still unique and have
> meaning to us.
>
> The value has been echoed back to us in the AllocationAck messages.
>
> But we are now talking to a different counter party and they are rejecting
> our Allocation Messages because they expect our values to be the same for
> both New Order Single and these Allocation Messages.
>
> Personally, I always thought they should have been the same, but it has
> not mattered until this new counter party.
>
> It would be easy enough to change our code to be consistent, but I'm just
> curious if this "requirement" makes sense?
>
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>



-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20180530/621a06c1/attachment.htm>


More information about the Quickfixn mailing list