Hi,
I am new with FIX. If our company sends a fix message (35=AE) which is then rejected by the receiver, is the receiver also supposed to register the failure in their systems? The receiver in this case is a software vendor and we would excpect them to have a rejections report to help with our fix messaging error handling.
Is this technically possible by the receiver? Thank you.
pstavroulis, I think in FIX 4.4 & 5.0 a Trade Capture Report (MsgType=AE) should be rejected by the application typically with a Trade Capture Report Ack (MsgType=AR). The FIX 4.4 & 5.0 spec say that “The Trade Capture Report Ack message can be: … Used to reject a trade capture report received from a counterparty.”
Note that if the Trade Capture Report fails session level rules, it could be rejected with a Session Level Reject (MsgType=3). But the message would need to fail session level validation for that, i.e. wrong checksum, body lenth, wrong routing tags, unknown fields if FIX validation being done by the FIX engine, etc.
There may be a little confusion with Trade Capture Reports, because the section in the FIX 4.4 & 5.0 spec for Business Level Rejects (MsgType=j) in Vol 1, lists the situation where Business Level Rejects should not be used. While that section says that it should not be used to reject a Trade Capture Report Request (MsgType=AD), but that section does NOT say that it should NOT be used to reject a Trade Capture Report. That section should probably have included that Trade Capture Reports should be rejected by a Trade Capture Report Ack, like is documented in the Trade Capture Report Ack section later in the document in VOl 5. Due to this inconsistency, some may think a Trade Capture Report should be rejected by a Business Level Reject.
Volume 1 of the FIX Specification defines the principle behind Business Message Reject as follows:
The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message should be issued.
The only exception to this rule is when a transport other than the FIX session protocol is being used (transport independence). An appropriate reject message of the given session protocol or the Business Message Reject message should be used instead.
Admittedly, the table in that section has not been updated properly as it does not contain the use case of a TCR submission being rejected by the receiver of the TCR. It also states the TCR as response to a TCRRequest whilst FIX 4.4 added a specific TCRRequestAck (35=AQ) for that purpose. But the principle works for any message, i.e. try to find a specific message and avoid the generic BusinessMessageReject whenever you can.