FIX session level reject

Question

I am studying fix session layer and having some confusion about session level reject.

In case of a garbled or invalid (error in checksum, bodylength, required tag missing...etc) received message during the session what will be the correct recovery measure? I am thinking about the following three:

1. Send a reject or LOGOUT message and include the reason in text field and DISCONNECT.
2. Send a REJECT message and include the reason (i.e. undefined tag ).
3. Disregard the garbled/erroneous message. In that case for the next received message a sequence gap will be detected and by sending ResendRequest FIX engine will recover the correct version of previously received garbled message.

Another thing is: is REJECT always followed by LOGOUT and DISCONNECTION ?

Thanks in advance.

Answer 1

Generally speaking, the correct response to an invalid message is just a session level reject (message type 3) that includes a sequence number of the message that it refers to in tag# 45 (RefSeqNum). The rest is optional. Including as much information as possible would generally help those folks dealing with the issue. Absence of that information may make it harder to diagnose the problem and result in a lot of customer requests and phone calls.

Disregarding a message is never a good idea. Just sending a logout is never a good idea either — it won’t be clear why the counter-party connection is requesting the end of session.

Whether to send a logout following a reject is totally up to you. Some systems do that, some don’t. And it doesn’t really matter because a logout is never helpful.

You see, if something happens that leads to an error such as absence of key fields in a message, or an invalid checksum is being generated — chances are that application is not written correctly, in which case it should be brought down immediately and fixed. Another possibility is a system failure (i.e. errors due to ionizing radiation ☺), in which case a graceful handling of the error is not possible.

These situations are common during a development and testing (certification) periods, and are almost never seen in production. In testing/staging/development environment, exchanges would simply reject a message with as much details as possible. That will hint developers as to what is wrong, they’ll correct the code and try again.

In production, having something like that happen is not acceptable and support department would need to get involved if it does. In case of infrequent errors, exchanges would simply send a reject. But you can imagine that a malfunctioning client may start sending millions (or a lot more) malformed messages. That can easily slow down the FIX gateway for all of the clients connected to it, or even cause a denial of service. This is not acceptable and exchanges employ different techniques to prevent it. Some have people constantly monitoring the situation and banning bad clients (using a firewall, for example) if they detect ridiculously high errors rates, then they would call the client to informing them of the situation. Other exchanges would reject a few messages, then send a logout if client is not fixing the error, and finally – automatically block the access. In extreme cases, clients may be denied a further access until passing certification again, and fined a fee for inconvenience. But that, of course, is beyond the scope of the FIX protocol.

Also, I have been writing financial applications for about a decade now, the company I am with right now is present on all US exchanges, and a lot of major exchanges across the world. Luckily, many of those don’t use FIX. But from a list of those using FIX, I have never seen a single one that complies with FIX protocol. Never. So your best bet would be to either follow exchange rules that you are connecting to (and they will NEVER send you bad messages, or if they do — you will have to call them up, sending a reject to them would be pointless), or if you are writing a server part — do the most logical thing that your clients would expect from you.

Hope it helps. Good Luck!