Done Trade Acks

, ,
1

Imported from previous forum

2

[ original email was from Kevin Bilello - kbilello@betasys.com ]
I have a question regarding acknowledging messages from compA who is sending us “done trades” for us to feed into our order management system on behalf of compB. I realize that the specs do not call for an individual message level ack, but I would like to be able to support that to communicate rejects and/or successes. First and foremost, I am more concerned with communicating a rejected trade than a good one.
Of the options below, I am leaning towards #5.
I’d greatly appreciate any suggestions:

  1. receive trades inbound (35=8) and
    if rejected
    send out an admin email (35=C) with the client order id referenced
    else
    send out an admin email (35=C) with the client order id referenced

  2. receive trades inbound (35=8) and
    if rejected
    send out a don’t know trade (35=Q) with the client order id referenced
    else
    send out an admin email (35=C) with the client order id referenced

  3. same as scenarios 1 & 2 but if the client chooses not to receive emails, then don’t send anything on a success

  4. same as scenarios 1 & 2 but if the client chooses not to receive emails, then send an execution message (35=8) echoing back the trade on a success

  5. create a new "user-defined" message type that handles acknowledging both cases.

3

#2 is the way that FIX would expect this to be implemented. The DK is the proper “reject” for the ExecutionRpt. The FIX session layer is an optomistic protocol and assumes receipt w/ seq nums used to detect any gaps. I know some other firms which have to know/acknowledge that the other side has received ExecRpts and what they do is after sending a set of ExecRpts they send a TestRequest and once they receive the Heartbeat w/ TestReqID for that TestRequest, then they consider that set of ExecRpts as “acknowledged”. This obviously only implies that the FIX engine on the other side received them not that they have been successfully processed at a business level. I guess email could be used as a way to force an explicit ack, however, I would highly recommend your #3 in which you are not forcing clients to receive/send them as it’s definitely atypical.

I think you’ll get push back on this idea from counterparties as there are tons of orders and execs being processed for all markets today, etc. and no one that I know of has resorted to explicit acks. Also as volume increases you might have more push back.

> I have a question regarding acknowledging messages from compA who is sending us “done trades” for us to feed into our order management system on behalf of compB. I realize that the specs do not call for an individual message level ack, but I would like to be able to support that to communicate rejects and/or successes. First and foremost, I am more concerned with communicating a rejected trade than a good one.
> Of the options below, I am leaning towards #5.
> I’d greatly appreciate any suggestions:
>
> 1) receive trades inbound (35=8) and
> if rejected
> send out an admin email (35=C) with the client order id referenced
> else
> send out an admin email (35=C) with the client order id referenced
>
> 2) receive trades inbound (35=8) and
> if rejected
> send out a don’t know trade (35=Q) with the client order id referenced
> else
> send out an admin email (35=C) with the client order id referenced
>
> 3) same as scenarios 1 & 2 but if the client chooses not to receive emails, then don’t send anything on a success
>
> 4) same as scenarios 1 & 2 but if the client chooses not to receive emails, then send an execution message (35=8) echoing back the trade on a success
>
> 5) create a new “user-defined” message type that handles acknowledging both cases.
>