Imported from previous forum
Hi All,
I’m wondering why the PriceType (423) field is not included in the SecurityDefinition message. Wouldn’t it be useful to specify how a security is priced?
Actually, PriceType is included in the SecurityDefinition message but it is a little hard to find.
With FIX 5 SP1, the area of reference data was significantly extended to capture all kinds of information related to the trading of securities. Previously, this kind of information all had to be documented somewhere whereas you can now convey it electronically. Also, the concept of market segments was introduced. You need to associate the security with at least one market segment to define the default PriceType as follows.
Each market segment contains SecurityTradingRules which consist of BaseTradingRules and TradingSessionRules. The base rules contain the PriceType field among a lot of other information.
Your SecurityDefinition message only needs to have the following:
48 SecurityID =
22 SecurityIDSource =
1310 NoMarketSegments = 1
1301 > MarketID = (recommended to use when defining a segment)
1300 > MarketSegmentID =
423 > PriceType =
You can then define in your rules of engagement that this default value may be overridden by a value in the order level messages. I do not know whether you allow your clients to tell you the price type they are using or if you set the price type by sending out reference data.
Regards,
Hanno.
Hi All,
I’m wondering why the PriceType (423) field is not included in the
SecurityDefinition message. Wouldn’t it be useful to specify how a
security is priced?
Would it be a terrible idea to just return PriceType with the SecurityDefinition as an added field for FIX4.2 clients? I don’t really want to force clients to use FIX5.0 and I also don’t want someone to submit an order thinking he is specifying price when we are expecting yield. Right now the plan is to require the PriceType be set in the NewOrderSingle message and if the type does not match the expected type we reject the order and the OrdRejReason text field will supply the proper PriceType, but of course that is less than ideal since the client has no reasonable way to divine what PriceType we expect except by assuming conventional pricing.
Actually, PriceType is included in the SecurityDefinition message but it
is a little hard to find.With FIX 5 SP1, the area of reference data was significantly extended to
capture all kinds of information related to the trading of securities.
Previously, this kind of information all had to be documented somewhere
whereas you can now convey it electronically. Also, the concept of
market segments was introduced. You need to associate the security with
at least one market segment to define the default PriceType as follows.Each market segment contains SecurityTradingRules which consist of
BaseTradingRules and TradingSessionRules. The base rules contain the
PriceType field among a lot of other information.Your SecurityDefinition message only needs to have the following:
48 SecurityID = 22 SecurityIDSource = 1310 NoMarketSegments = 1 1301 > MarketID =
(recommended to use when defining a segment) 1300 > MarketSegmentID =
423 > PriceType =You can then define in your rules of engagement that this default value
may be overridden by a value in the order level messages. I do not know
whether you allow your clients to tell you the price type they are using
or if you set the price type by sending out reference data.Regards, Hanno.
Hi All,
I’m wondering why the PriceType (423) field is not included in the
SecurityDefinition message. Wouldn’t it be useful to specify how a
security is priced?
If FPL were to do this, then there is hardly a reason ever to move away from FIX 4.2. The FIX spec is not a piece of software but it seems to be the only versioned object where there is a strong desire to extend the capabilities without changing the version number. FIX 4.2 will be 10 years old in less than half a year. In my view it is becoming more of a marketing label than a reflection of what it offers. People have real needs to extend their functionality but assume that a move to FIX 5 is a major step. It is much less of an effort if you look into the details.
Here is a way out for you: use tag 6391 or 6614 or 9904. They are all called “PriceType” and might fit your needs and will not be rejected by a standard FIX engine. There are about 10 more user-defined tags with the term “PriceType” in them that might also qualify.
Would it be a terrible idea to just return PriceType with the
SecurityDefinition as an added field for FIX4.2 clients? I don’t really
want to force clients to use FIX5.0 and I also don’t want someone to
submit an order thinking he is specifying price when we are expecting
yield. Right now the plan is to require the PriceType be set in the
NewOrderSingle message and if the type does not match the expected type
we reject the order and the OrdRejReason text field will supply the
proper PriceType, but of course that is less than ideal since the client
has no reasonable way to divine what PriceType we expect except by
assuming conventional pricing.