Order History and position information

, ,
1

Imported from previous forum

2

Hi,

  1. I’ve been looking for a way to relay de history of a given order (it’s subsequent states (new, accepted, filled etc)) to a client on request, but I can’t really come up with a way to do this through FIX; Apperently FIX only deals with current statuses?

  2. Another problem I’m having is communicating the content of a clients portfolio through FIX on request of this client. Same problem here.

Is there a way to do this or am I simply using the wrong protocol to solve these problems?

Thanks

3

Hi,

  1. I’ve been looking for a way to relay de history of a given order
    (it’s subsequent states (new, accepted, filled etc)) to a client on
    request, but I can’t really come up with a way to do this through
    FIX; Apperently FIX only deals with current statuses?

  2. Another problem I’m having is communicating the content of a clients
    portfolio through FIX on request of this client. Same problem here.

Is there a way to do this or am I simply using the wrong protocol to
solve these problems?

Thanks

There is no exact match in FIX to accomplish what you want, but you can customize existing messages and session behavior to accomplish it, as long you and your counterparties agree. One of the benefits of FIX is that customizations between parties are not only supported, but quite common. In fact, many customizations determined to be useful to a wider audience have been integrated into the core specification.

For scenario one, your counterparty could send you a OrderStatusRequest(H) message, specifying the ClOrdID(11) of the order to retrieve the full status of as well as a unique OrdStatusReqID(790). Upon receipt of an OrderStatusRequest, your application would lookup all of the ExecutionReport(8) messages related to that ClOrdID and send them back to the client with the PossResendFlag(97) field set to ‘Y’. The PossResendFlag is used in FIX to indicate new message is being sent with business content that may have been sent before.

Your counterparty would be expecting these PossResend messages as the response to their OrderStausRequest and process them accordingly. To provide an extra check to indicate the PossResend executions were not sent for another reason, the OrdStatusReqID field would be sent on these resent ExectionReport messages to provide a link to the OrderStatusRequest.

In your second scenario, can you clarify what status you are looking to relate? Do you need to send the current status of each position or of every order?

Andrew Broome
TransactTools, Inc

4

Hi Andrew,

Thanks for your quick and to the point response.

For communicating a client’s portfolio through FIX, it indeed involves sending the current status of all of the orders in this clients portfolio. I think I would have to use a similar mechanism as the one you allready suggested: Execution Reports with PossResend flag set and a RequestId. As request message (see next reply in theis thread by scot Atwell) I could use the Order Mass Status Request.

Thanks a lot

Stef

Hi,

  1. I’ve been looking for a way to relay de history of a given order
    (it’s subsequent states (new, accepted, filled etc)) to a client on
    request, but I can’t really come up with a way to do this through
    FIX; Apperently FIX only deals with current statuses?

  2. Another problem I’m having is communicating the content of a
    clients portfolio through FIX on request of this client. Same
    problem here.

Is there a way to do this or am I simply using the wrong protocol to
solve these problems?

Thanks

There is no exact match in FIX to accomplish what you want, but you can
customize existing messages and session behavior to accomplish it, as
long you and your counterparties agree. One of the benefits of FIX is
that customizations between parties are not only supported, but quite
common. In fact, many customizations determined to be useful to a wider
audience have been integrated into the core specification.

For scenario one, your counterparty could send you a
OrderStatusRequest(H) message, specifying the ClOrdID(11) of the order
to retrieve the full status of as well as a unique OrdStatusReqID(790).
Upon receipt of an OrderStatusRequest, your application would lookup all
of the ExecutionReport(8) messages related to that ClOrdID and send them
back to the client with the PossResendFlag(97) field set to ‘Y’. The
PossResendFlag is used in FIX to indicate new message is being sent with
business content that may have been sent before.

Your counterparty would be expecting these PossResend messages as the
response to their OrderStausRequest and process them accordingly. To
provide an extra check to indicate the PossResend executions were not
sent for another reason, the OrdStatusReqID field would be sent on these
resent ExectionReport messages to provide a link to the
OrderStatusRequest.

In your second scenario, can you clarify what status you are looking to
relate? Do you need to send the current status of each position or of
every order?

Andrew Broome TransactTools, Inc

5

You might take a look at the “Order Mass Status Request” message that was added in FIX 4.3 which partially addresses your needs.

Hi,

  1. I’ve been looking for a way to relay de history of a given order
    (it’s subsequent states (new, accepted, filled etc)) to a client on
    request, but I can’t really come up with a way to do this through
    FIX; Apperently FIX only deals with current statuses?

  2. Another problem I’m having is communicating the content of a clients
    portfolio through FIX on request of this client. Same problem here.

Is there a way to do this or am I simply using the wrong protocol to
solve these problems?

Thanks