Imported from previous forum
[ original email was from Koji Ishikawa - ishikawa@quick.co.jp ]
Quick, which is a part of technical working
group in Japan currently, is planning to
provide FIX message routing service between
buy side and sell side.
The possible problem is that ClOrdID is
supposed to be unique by institution, however,
if mulitple buy side happen to put the same
value in this field and send orders to the
same sell side, it will not be unique
anymore on the sell side. This seems to be
very likely if everyone uses sequence numbers
for the field.
Are sell side firms supposed to combine
"OnBehalfOf" field and "ClOrderID" to
make up an unique value within their system?
Or is the service vendor, such as Quick,
supposed to convert ClOrdID to some
unique value and deliver to the sell side?
In this case, the buy side and sell side
probably need to know what the converted
value is, which may be very confusing.
[ original email was from Mark Hinman - mhinman@easetech.com ]
> Quick, which is a part of technical working
> group in Japan currently, is planning to
> provide FIX message routing service between
> buy side and sell side.
>
> The possible problem is that ClOrdID is
> supposed to be unique by institution, however,
> if mulitple buy side happen to put the same
> value in this field and send orders to the
> same sell side, it will not be unique
> anymore on the sell side. This seems to be
> very likely if everyone uses sequence numbers
> for the field.
>
> Are sell side firms supposed to combine
> "OnBehalfOf" field and "ClOrderID" to
> make up an unique value within their system?
>
> Or is the service vendor, such as Quick,
> supposed to convert ClOrdID to some
> unique value and deliver to the sell side?
> In this case, the buy side and sell side
> probably need to know what the converted
> value is, which may be very confusing.
>
>
If a message is received across FIX, then the combination of SenderCompID and ClOrdID (or any other ID) forms the unique identifier. Any internally generated message is inherently unique.
If a single FIX session represents multiple firms, then the sellside to use OnBehalfOfCompID + ClOrdID. OnBehalfOfCompID will identify the institution and the ClOrdID should be unique for that institution. Do you have a situtation in which for a single OnBehalfOfCompID, the ClOrdID value would not be unique?
> > Quick, which is a part of technical working
> > group in Japan currently, is planning to
> > provide FIX message routing service between
> > buy side and sell side.
> >
> > The possible problem is that ClOrdID is
> > supposed to be unique by institution, however,
> > if mulitple buy side happen to put the same
> > value in this field and send orders to the
> > same sell side, it will not be unique
> > anymore on the sell side. This seems to be
> > very likely if everyone uses sequence numbers
> > for the field.
> >
> > Are sell side firms supposed to combine
> > "OnBehalfOf" field and "ClOrderID" to
> > make up an unique value within their system?
> >
> > Or is the service vendor, such as Quick,
> > supposed to convert ClOrdID to some
> > unique value and deliver to the sell side?
> > In this case, the buy side and sell side
> > probably need to know what the converted
> > value is, which may be very confusing.
> >
> >
>
> If a message is received across FIX, then the combination of SenderCompID and ClOrdID (or any other ID) forms the unique identifier. Any internally generated message is inherently unique.
>
[ original email was from Koji Kubota - koji.kubota@gs.com ]
In Japan extension working group, which is
discussing how to use FIX in Japan, we
have agreed that senders placing orders
are responsible for putting unique values
in ClOrdID. We can assume that the ClOrdID
value is unique for a single OnBehalfOfCompID.
>> If a single FIX session represents multiple firms, then the sellside to use OnBehalfOfCompID + ClOrdID. OnBehalfOfCompID will identify the institution and the ClOrdID should be unique for that institution. Do you have a situtation in which for a single OnBehalfOfCompID, the ClOrdID value would not be unique?
It seems that sell side should do the following;
if OnBehalfOfComID exists then
use OnBehalfOfCompID + ClOrdID
else
use SenderCompID + ClOrdID
A third party between sell and buy side
should not convert ClOrdID, and it is
a responsiblity of sell side (receiver)
to use the logic mentioned above.
Is there anyone in US, who had some
problem regarding this issue? As far as
I know of, Bloomberg is doing the switching
service. Did Bloomberg do anything with
ClOrdID?
> > If a message is received across FIX, then the combination of SenderCompID and ClOrdID (or any other ID) forms the unique identifier. Any internally generated message is inherently unique.
> >