Imported from previous forum
Hi,
we are writing up our Fix interface spec for our client for vendor access to their system.
Counter orders don’t seem to be part of Fix spec.
i.e. a new order is countered with a new shares or price.
Any suggestions on how to do this?
the clients internal system has a message type counter but the Fix gateway has to do the translation from whatever we specify for vendors to use.
what is the most Fixy or standard way people are specing this ?
we are thinking that maybe the receiver(fix vendor client) of the new order can counter it by sending back a execution report with ExecType set to "Reject" but specifying a different price and/or size than the original order.
thanks for info.
What you’re describing is the negotiation process. The negotiation model is being proposed for the forth coming FIX 4.4 release. The model is being proposed in the fixed income context. Please go to the Fixed Income Working Groups section and download the FI proposal (FIWG - Gap Analysis - Updated - FIWG4.4GapAnalysis.doc) and take a look at the FI model. We would be keen on any feedback your client has on the proposed model. Those feedback comments can be posted to the 4.4 Changes discussion area.
> Hi,
>
> we are writing up our Fix interface spec for our client for vendor access to their system.
>
> Counter orders don’t seem to be part of Fix spec.
>
> i.e. a new order is countered with a new shares or price.
>
>
> Any suggestions on how to do this?
>
> the clients internal system has a message type counter but the Fix gateway has to do the translation from whatever we specify for vendors to use.
>
> what is the most Fixy or standard way people are specing this ?
>
> we are thinking that maybe the receiver(fix vendor client) of the new order can counter it by sending back a execution report with ExecType set to “Reject” but specifying a different price and/or size than the original order.
>
>
>
>
> thanks for info.
>
parden my ignorance, but I know as much as I have to learn to develop the fix interface.
I looked at the doc and not sure if it applies to my situation.
The flow of Fixed Income security classes speced in the document are for corp bond, municipal secs, agency secs, us. trasury secs, mortgage backed secs, euro soverign and corp bonds.
Do they apply to OTC market orders/counter orders and such?
that is the market I am developing for.
> What you’re describing is the negotiation process. The negotiation model is being proposed for the forth coming FIX 4.4 release. The model is being proposed in the fixed income context. Please go to the Fixed Income Working Groups section and download the FI proposal (FIWG - Gap Analysis - Updated - FIWG4.4GapAnalysis.doc) and take a look at the FI model. We would be keen on any feedback your client has on the proposed model. Those feedback comments can be posted to the 4.4 Changes discussion area.
>
>
> > Hi,
> >
> > we are writing up our Fix interface spec for our client for vendor access to their system.
> >
> > Counter orders don’t seem to be part of Fix spec.
> >
> > i.e. a new order is countered with a new shares or price.
> >
> >
> > Any suggestions on how to do this?
> >
> > the clients internal system has a message type counter but the Fix gateway has to do the translation from whatever we specify for vendors to use.
> >
> > what is the most Fixy or standard way people are specing this ?
> >
> > we are thinking that maybe the receiver(fix vendor client) of the new order can counter it by sending back a execution report with ExecType set to “Reject” but specifying a different price and/or size than the original order.
> >
> >
> >
> >
> > thanks for info.
> >
>
The negotiation model is proposed as part of the fixed income proposal because the model currently doesn’t exist in FIX - the model is meant to be asset type neutral, therefore you should be able to apply it to the negotiation of any asset.
As it sounds like that your client is interested in a negotiation model for OTC equity, we are interested in their feed back as to whether the proposed negotiation model will work for OTC equity neogitiation or not - if not what needs to be changed to make it work for equities. Since the model is still in a proposed status we can make changes.
Hope this helps. If you have more questions please email me directly and we can discuss off-line.
> parden my ignorance, but I know as much as I have to learn to develop the fix interface.
>
> I looked at the doc and not sure if it applies to my situation.
>
> The flow of Fixed Income security classes speced in the document are for corp bond, municipal secs, agency secs, us. trasury secs, mortgage backed secs, euro soverign and corp bonds.
>
> Do they apply to OTC market orders/counter orders and such?
>
> that is the market I am developing for.
>
>
>
>
>
>
>
>
> > What you’re describing is the negotiation process. The negotiation model is being proposed for the forth coming FIX 4.4 release. The model is being proposed in the fixed income context. Please go to the Fixed Income Working Groups section and download the FI proposal (FIWG - Gap Analysis - Updated - FIWG4.4GapAnalysis.doc) and take a look at the FI model. We would be keen on any feedback your client has on the proposed model. Those feedback comments can be posted to the 4.4 Changes discussion area.
> >
> >
> > > Hi,
> > >
> > > we are writing up our Fix interface spec for our client for vendor access to their system.
> > >
> > > Counter orders don’t seem to be part of Fix spec.
> > >
> > > i.e. a new order is countered with a new shares or price.
> > >
> > >
> > > Any suggestions on how to do this?
> > >
> > > the clients internal system has a message type counter but the Fix gateway has to do the translation from whatever we specify for vendors to use.
> > >
> > > what is the most Fixy or standard way people are specing this ?
> > >
> > > we are thinking that maybe the receiver(fix vendor client) of the new order can counter it by sending back a execution report with ExecType set to “Reject” but specifying a different price and/or size than the original order.
> > >
> > >
> > >
> > >
> > > thanks for info.
> > >
> >
>