Silently ignore unsupported optional fields or reject?

[berntsanden_x]

Imported from previous forum

[berntsanden_x]

Hi,

I can think of the following ways of handling unsupported optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to reject a New Order Single, indicating that the field is not supported.
3. Exclude the non supported field in our FIX repository which will have the effect that we send a session level reject instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt

[fplpo_x]

[ original email was from Sunil Bopche - sunil_bopche@ml.com ]

Hi,
That depends on what kind of application you are writing. If you are writing a FIX Engine then ideally unsupported tags should be rejected by sending a session level reject message with reject reason in tag 58 like “Unsupported tag XXX” .

• Sunil

Hi,

I can think of the following ways of handling unsupported
optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to
   reject a New Order Single, indicating that the field is not
   supported. 3) Exclude the non supported field in our FIX repository
   which will have the effect that we send a session level reject
   instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt

[hanno.klein]

Hi Bernt,

I would not silently ignore the field, assuming that the sender wanted to either convey information or ask for a certain trading behaviour. I consider it to be best practice to avoid sending redundant fields and to point it out to the sender if unexpected fields are sent.

As it is functional information that cannot be processed by the specific receiver, the business level reject should be used. Other receivers might support the requested functionality and accept the message as is.

Reducing the repository and converting it to a technical error does not seem the right approach to me. It could even lead to the wrong people on the sender side dealing with the error and then (rightfully) claiming that the receiver does not follow the FIX spec.

Regards,
Hanno.

Hi,

I can think of the following ways of handling unsupported
optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to
   reject a New Order Single, indicating that the field is not
   supported. 3) Exclude the non supported field in our FIX repository
   which will have the effect that we send a session level reject
   instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt

[berntsanden_x]

Hi Hanno,

Thanks for your valuable input. It seems that we have to keep the full FIX repository and to send the proper business level reject when unsupported optional fields are received.

Regards, Bernt

Hi Bernt,

I would not silently ignore the field, assuming that the sender wanted
to either convey information or ask for a certain trading behaviour. I
consider it to be best practice to avoid sending redundant fields and to
point it out to the sender if unexpected fields are sent.

As it is functional information that cannot be processed by the specific
receiver, the business level reject should be used. Other receivers
might support the requested functionality and accept the message as is.

Reducing the repository and converting it to a technical error does not
seem the right approach to me. It could even lead to the wrong people on
the sender side dealing with the error and then (rightfully) claiming
that the receiver does not follow the FIX spec.

Regards, Hanno.

Hi,

I can think of the following ways of handling unsupported
optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to
   reject a New Order Single, indicating that the field is not
   supported. 3) Exclude the non supported field in our FIX repository
   which will have the effect that we send a session level reject
   instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt

[johnpeng13_x]

I would say that option 3 is the way to go. Be careful thought that the custom FIX repository is supposed to be a true reflection of your own FIX spec – so you only exclude the fields that are not supported in your spec. In other words, no “creativity” is allowed in the repository itself, and any change should start with your spec.

Just my two cents…

Hi,

I can think of the following ways of handling unsupported
optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to
   reject a New Order Single, indicating that the field is not
   supported. 3) Exclude the non supported field in our FIX repository
   which will have the effect that we send a session level reject
   instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt

[hanno.klein]

You would then give up the distinction between “non-standard” and “invalid” which I believe is of value to have. The documentation, e.g. FIXimate, and the development repository (e.g. for code generation) can and should be reduced to the subset of used messages, fields and enum values but not the repository running in production in the FIX engine. This guarantees that rejections of unsupported elements occur on the application/business level and functional experts deal with the issues.

I would say that option 3 is the way to go. Be careful thought that the
custom FIX repository is supposed to be a true reflection of your own
FIX spec – so you only exclude the fields that are not supported in
your spec. In other words, no “creativity” is allowed in the repository
itself, and any change should start with your spec.

Just my two cents…

Hi,

I can think of the following ways of handling unsupported
optional fields:

1. Silently ignore the field.
2. Send a business level reject, for example an ExecutionReport to
   reject a New Order Single, indicating that the field is not
   supported. 3) Exclude the non supported field in our FIX repository
   which will have the effect that we send a session level reject
   instead with 373=3 (undefined tag) as we do not recognize that tag.

Please advise

Regards, Bernt