Question About CollateralInquiryAck and RequestForPositionsAck

, ,
1

Imported from previous forum

2

We have a FIX engine which sends CollateralReports and PositionReports on demand.

FIX clients send their requests via CollateralInquiries and RequestForPositions.

We use the CollateralInquiryAck and RequestForPositionAck to reject non-valid queries.

We were pondering whether a CollateralInquiryAck and RequestForPositionAck should be sent when queries are valid.

It appears to be unnecessary but I can’t work out exactly what the spec recommends.

Can somebody help ?

Thanks

3

XXXAck messages for valid requests are subject to bilateral agreements where explicit acknowledgements of all requests are useful, positive or negative. Report messages might go over a different channel than the one used by the submitter of the request. If the submitter does not get an ACK back he does not know if his request was valid or if it was invalid and the negative ACK is simply delayed. It there is only a single channel, then the first report responding to the request can serve as positive ACK. Another reason to acknowledge a valid request is when the result set of the request is empty, i.e. when there is no report message to be sent which could serve as an implicit positive ACK.
Regards,
Hanno.

We have a FIX engine which sends CollateralReports and PositionReports on demand.

FIX clients send their requests via CollateralInquiries and RequestForPositions.

We use the CollateralInquiryAck and RequestForPositionAck to reject non-valid queries.

We were pondering whether a CollateralInquiryAck and RequestForPositionAck should be sent when queries are valid.

It appears to be unnecessary but I can’t work out exactly what the spec recommends.

Can somebody help ?

Thanks

4

[ original email was from Chris Snell - Chris.snell@patsystems.com ]
FIX 5.0 spec vol 5 you will see the following:

for the Collateral Inquiry Ack:

FIX Protocol defines this message as only being received in the following situations:

Used to respond to a Collateral Inquiry in the following situations:
• When the CollateralInquiry will result in an out of band response (such as a file transfer).
• When the inquiry is otherwise valid but no collateral is found to match the criteria specified on the Collateral Inquiry message.
• When the Collateral Inquiry is invalid based upon the business rules of the counterparty.

So are you saying its fine to go against this and send a positive ack as long as its agreed bewteen parties?

AND for Request For Positions Ack

This message is defined as follows:

The Request for Positions Ack message is returned by the holder of the position in response to a Request for Positions message. The purpose of the message is to acknowledge that a request has been received and is being processed.

Our problem here is with TAG 729 PosReStatus which has the following values:

0 = Completed
1 = Completed With Warnings
2 = Rejected

We believe it could cause confusion as if an ack is received for the request for positions with completed status before the postion reports are received, some applications might see this as completed throw up errors.

this is single channel so we dont have the issue you described below.

Is it not a contradiction to say you need the positive ack if “the first report responding to the request can serve as positive ACK”.

Chris

XXXAck messages for valid requests are subject to bilateral agreements where explicit acknowledgements of all requests are useful, positive or negative. Report messages might go over a different channel than the one used by the submitter of the request. If the submitter does not get an ACK back he does not know if his request was valid or if it was invalid and the negative ACK is simply delayed. It there is only a single channel, then the first report responding to the request can serve as positive ACK. Another reason to acknowledge a valid request is when the result set of the request is empty, i.e. when there is no report message to be sent which could serve as an implicit positive ACK.
Regards,
Hanno.

We have a FIX engine which sends CollateralReports and PositionReports on demand.

FIX clients send their requests via CollateralInquiries and RequestForPositions.

We use the CollateralInquiryAck and RequestForPositionAck to reject non-valid queries.

We were pondering whether a CollateralInquiryAck and RequestForPositionAck should be sent when queries are valid.

It appears to be unnecessary but I can’t work out exactly what the spec recommends.

Can somebody help ?

Thanks

5

The spec is always a good source but not a 100% comprehensive document. If you want to be exact about the text then I would say it is your interpretation that it is a complete list. The spec does not say “only” but lists three situations in which you would use it. I have added a fourth one where it makes sense. That is why the Rules of Engagement (RoE) exist between parties using the FIX protocol so that one can limit it to the subset of functionality provided but then define 100% of the that behaviour. I do not see any harm in providing an ACK for a valid request that results in one or more reports.
I agree regarding the potential confusion when sending “completed” prior to having sent the requested reports themselves. Again, you can be more precise in your RoE to explain that it only means that you have triggered the action to send the reports. Or you can wait with the ACK until you have actually sent the reports. Tag 722 PosMaintStatus shows you how it could look like, i.e. it also has a value “accepted” to express what you are describing. You could submit a Gap Analysis to FPL and ask for an extension to add such values.
I did not say “you need the positive ack if “the first report responding to the request can serve as positive ACK””. I said “If there is only a single channel, then…” (I had a typo in the first word). I meant to say that you do not need an explicit ACK if you send at least one report because this report then tells the submitter of the request that it must have been valid. The report carries 710 PosReqID and is an implicit ACK.
You can stick to the FIX spec and only send an ACK in the cases defined there but you can generally not make any assumptions on whether something that is not described in the spec is allowed or now. It depends on the context, your counterparties and often just common sense.
Hope I could clarify,
Hanno.

FIX 5.0 spec vol 5 you will see the following:

for the Collateral Inquiry Ack:

FIX Protocol defines this message as only being received in the following situations:

Used to respond to a Collateral Inquiry in the following situations:
• When the CollateralInquiry will result in an out of band response (such as a file transfer).
• When the inquiry is otherwise valid but no collateral is found to match the criteria specified on the Collateral Inquiry message.
• When the Collateral Inquiry is invalid based upon the business rules of the counterparty.

So are you saying its fine to go against this and send a positive ack as long as its agreed bewteen parties?

AND for Request For Positions Ack

This message is defined as follows:

The Request for Positions Ack message is returned by the holder of the position in response to a Request for Positions message. The purpose of the message is to acknowledge that a request has been received and is being processed.

Our problem here is with TAG 729 PosReStatus which has the following values:

0 = Completed
1 = Completed With Warnings
2 = Rejected

We believe it could cause confusion as if an ack is received for the request for positions with completed status before the postion reports are received, some applications might see this as completed throw up errors.

this is single channel so we dont have the issue you described below.

Is it not a contradiction to say you need the positive ack if “the first report responding to the request can serve as positive ACK”.

Chris

XXXAck messages for valid requests are subject to bilateral agreements where explicit acknowledgements of all requests are useful, positive or negative. Report messages might go over a different channel than the one used by the submitter of the request. If the submitter does not get an ACK back he does not know if his request was valid or if it was invalid and the negative ACK is simply delayed. It there is only a single channel, then the first report responding to the request can serve as positive ACK. Another reason to acknowledge a valid request is when the result set of the request is empty, i.e. when there is no report message to be sent which could serve as an implicit positive ACK.
Regards,
Hanno.

We have a FIX engine which sends CollateralReports and PositionReports on demand.

FIX clients send their requests via CollateralInquiries and RequestForPositions.

We use the CollateralInquiryAck and RequestForPositionAck to reject non-valid queries.

We were pondering whether a CollateralInquiryAck and RequestForPositionAck should be sent when queries are valid.

It appears to be unnecessary but I can’t work out exactly what the spec recommends.

Can somebody help ?

Thanks