Imported from previous forum
[ original email was from mike aikins - mike.aikins@securitiesstrategy.com ]
We are working with an organisation building an ordr routing network and I was wondering what the accepted "best practice" is when the Order Routing network recieves an order that it cannot deliver to the destination broker (network link down etc…)…
Do we send an Exception Report (Rejected) ?
Regards
MikeA
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> We are working with an organisation building an ordr routing network and I was wondering what the accepted "best practice" is when the Order Routing network recieves an order that it cannot deliver to the destination broker (network link down etc…)…
>
> Do we send an Exception Report (Rejected) ?
Yes, rejecting the order at the application level is preferable.
[ original email was from Richard Campbell - rich.campbell@db.com ]
> We are working with an organisation building an ordr routing network and I was wondering what the accepted "best practice" is when the Order Routing network recieves an order that it cannot deliver to the destination broker (network link down etc…)…
>
> Do we send an Exception Report (Rejected) ?
Except an order routing network isn’t at “the
application level”. I think the purpose of an
order routing network is to be transparent
to both sides of the conversation. As a
counter-example, you might thing you want to send
an Execution Report indicating rejection if a New
Order can’t be delivered. But what if the New
Order was delivered and acknowledged, and now an
Order Status message comes in with the network
to the broker down? I don’t think there’s a
reasonable message you can send back. If we start
to send back application level messages (Order
Status reject, Cancel Reject, etc) we’re giving
back the sender application level semantics which
we do not possess. E.g., what do you send back
if you can’t deliver an Email message?
And if you do send an Exec Report with a Reject
status, how do you construct the ExecID so that
you can prove it will not be duplicated by any
other Execution Report which could subsequently
be sent by a broker?
The thing is that FIX Messages are application
level and we don’t have routing level
messages. How about we add a field to the
Header? There are already messages in the Header
which relate to session-level and routing issues
(OnBehalfOf). So, if I could echo the message
back to the buyer with a “RoutingReject” field
which says “Route Down”, that would make sense.
– Richard Campbell
Deutsche Banc Alex. Brown
[ original email was from Jeremy Sevareid - jsevareid@randomwalk.com ]
Check out 4.2’s Business Level Reject message. It lists the rejects appropriate to particular message types and situations. In the case in which an order routing network can’t deliver the message:
"Note the only exception to this rule is in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system. In this situation a Business Message Reject with BusinessRejectReason = “Application not available at this time” can be issued if the the system is unable to send the specific “reject” message listed above due to this condition."
> > We are working with an organisation building an ordr routing network and I was wondering what the accepted “best practice” is when the Order Routing network recieves an order that it cannot deliver to the destination broker (network link down etc…)…
> >
> > Do we send an Exception Report (Rejected) ?
>
> Except an order routing network isn’t at “the
> application level”. I think the purpose of an
> order routing network is to be transparent
> to both sides of the conversation. As a
> counter-example, you might thing you want to send
> an Execution Report indicating rejection if a New
> Order can’t be delivered. But what if the New
> Order was delivered and acknowledged, and now an
> Order Status message comes in with the network
> to the broker down? I don’t think there’s a
> reasonable message you can send back. If we start
> to send back application level messages (Order
> Status reject, Cancel Reject, etc) we’re giving
> back the sender application level semantics which
> we do not possess. E.g., what do you send back
> if you can’t deliver an Email message?
>
> And if you do send an Exec Report with a Reject
> status, how do you construct the ExecID so that
> you can prove it will not be duplicated by any
> other Execution Report which could subsequently
> be sent by a broker?
>
> The thing is that FIX Messages are application
> level and we don’t have routing level
> messages. How about we add a field to the
> Header? There are already messages in the Header
> which relate to session-level and routing issues
> (OnBehalfOf). So, if I could echo the message
> back to the buyer with a “RoutingReject” field
> which says “Route Down”, that would make sense.
>
>
> – Richard Campbell
> Deutsche Banc Alex. Brown
>
>