What to do if FIX specs not followed?

, ,
1

Imported from previous forum

2

I am currently in the process of implementing a FIX engine, according to FIX version 4.1.

The development team has raised an interesting question: If a FIX message is received but the message is not entirely according to the protocol specs, do we: 1) send a reject, or 2) send to the FIX application anyway but with a warning?

An example of a ‘bad’ FIX message would be an instance where a TAG # > 10000 is used.

Given that the FIX specs state the FIX application should make the decision where possible, should this be an automatic reject by the FIX engine or accepted with some warning flag? I can see an argument for both sides.

What does everyone else do or recommend?

Thanks for any help!

3

Brian,

I can’t speak for the general FIX community, but what I personally do is:

  1. Check that the message ‘looks’ like a FIX message; i.e. that the general format is <tag>=<value>, and there are <SOH> delimiters where expected. If not, discard your input buffer as it cannot be considered reliable.

  2. Check the general integrity of the message - the first 3 fields should be constant, the last should be the checksum, the version is correct, the bodylength checks out and the checksum is correct. If not, discard this message.

Note: for the above 2 cases, if you ignore the message, the next good one you receive will have a sequence number greater than you expected. You then send a resend request to the client and wait for the correct sequence number to arrive. If it doesn’t within a timeout period, log the client out.

  1. Validate the header - is the client known to you, do they want to speak to you (compid’s), sequence number. If not, ignore the message.

  2. Only if the above checks are ok should you look at the content of the message according to the message type. For example, if you got an order single and something was wrong in the order (e.g. you already had the order before), you should send a REJECT message.

So, in summary, ignore a bad message which can’t be identified as a good FIX message, and reject messages which look ok but the content is not what you logically expected.

Hope this helps,

Peter Sen
FIX consultant, Sydney.

> I am currently in the process of implementing a FIX engine, according to FIX version 4.1.
>
> The development team has raised an interesting question: If a FIX message is received but the message is not entirely according to the protocol specs, do we: 1) send a reject, or 2) send to the FIX application anyway but with a warning?
>
> An example of a ‘bad’ FIX message would be an instance where a TAG # > 10000 is used.
>
> Given that the FIX specs state the FIX application should make the decision where possible, should this be an automatic reject by the FIX engine or accepted with some warning flag? I can see an argument for both sides.
>
> What does everyone else do or recommend?
>
> Thanks for any help!
>