Imported from previous forum
We need to handle "Execution" information and would prefer to use a non-proprietary format, e.g. FIXML.
We currently use FIXML in-house.
However, FIXML4.x does not handle Execution data. It does have an "ExecutionReport" but a better name for this would be "OrderStatusReport" as it models the information it passes back to a Client to indicate the status of an Order. For example, an ExecutionReport does not contain Local Gross/Net Prices or Trading Books.
In the absence of a better suggestion, I intend to implement an “Execution” as a top-level FIXML ApplicationMessage. I will base the Execution on ExecutionReport but will remove those elements that are not relevant to an Execution (e.g. LeavesQty) and add elements that are required (e.g. LocalGrossPx, LocalNetPx, TradingBook)
Any suggestions greatly appreciated.
Ian Relf
[ original email was from Dwight Arthur - darthur@dtcc.com ]
Your question is really not about FixML, because FixML copies its fields from FIX - so what you are asking for, apparently, is an execution message with LeavesQty and maybe other fields made optional, and some new fields added. If this were accepted as part of the FIX 4.3 spec then (according to current schedules) it would become part of FixML this August.
I am working with the Technical Steering Committee on proposed changes to the ExecutionReport to make it suitable for reporting executed trades by an exchange or ECN into the clearance & settlement infrastructure - e.g. central counterparties, central securities depositories, etc. We are proposing new fields to recognize that there is a sell broker and a buy broker, each with its own clearing firm, capacity, etc. There are some other new fields as well, like identifying the system on which an exchange executed the order.
It has been suggested by at least one member of the committee that we should keep this new stuff out of the ExecutionReport, and instead, place it into a new "Trade report" message. Does this seem relevant to your interests?
Finally, could you explain the meaning of LocalGrossPx, LocalNetPx, and TradingBook?
Dwight Arthur
DTCC
> We need to handle "Execution" information and would prefer to use a non-proprietary format, e.g. FIXML.
> We currently use FIXML in-house.
> However, FIXML4.x does not handle Execution data. It does have an "ExecutionReport" but a better name for this would be "OrderStatusReport" as it models the information it passes back to a Client to indicate the status of an Order. For example, an ExecutionReport does not contain Local Gross/Net Prices or Trading Books.
> In the absence of a better suggestion, I intend to implement an “Execution” as a top-level FIXML ApplicationMessage. I will base the Execution on ExecutionReport but will remove those elements that are not relevant to an Execution (e.g. LeavesQty) and add elements that are required (e.g. LocalGrossPx, LocalNetPx, TradingBook)
>
> Any suggestions greatly appreciated.
>
> Ian Relf
>
>
>
The issue I found in working with the Execution Report message is that it tries to represent two distinct (but related) entities with one message - an order and it’s current status, and an execution (related to an order). I agree that the execution report should be split into two separate messages as is suggested by your notion of a “Trade Report”. One message would contain information pertaining to the Order another would contain Execution information.
Jim Downs
Connamara Systems, LLC
Chicago, IL
> Your question is really not about FixML, because FixML copies its fields from FIX - so what you are asking for, apparently, is an execution message with LeavesQty and maybe other fields made optional, and some new fields added. If this were accepted as part of the FIX 4.3 spec then (according to current schedules) it would become part of FixML this August.
>
> I am working with the Technical Steering Committee on proposed changes to the ExecutionReport to make it suitable for reporting executed trades by an exchange or ECN into the clearance & settlement infrastructure - e.g. central counterparties, central securities depositories, etc. We are proposing new fields to recognize that there is a sell broker and a buy broker, each with its own clearing firm, capacity, etc. There are some other new fields as well, like identifying the system on which an exchange executed the order.
>
> It has been suggested by at least one member of the committee that we should keep this new stuff out of the ExecutionReport, and instead, place it into a new "Trade report" message. Does this seem relevant to your interests?
>
> Finally, could you explain the meaning of LocalGrossPx, LocalNetPx, and TradingBook?
> Dwight Arthur
> DTCC
> - - - - -
> > We need to handle "Execution" information and would prefer to use a non-proprietary format, e.g. FIXML.
> > We currently use FIXML in-house.
> > However, FIXML4.x does not handle Execution data. It does have an "ExecutionReport" but a better name for this would be "OrderStatusReport" as it models the information it passes back to a Client to indicate the status of an Order. For example, an ExecutionReport does not contain Local Gross/Net Prices or Trading Books.
> > In the absence of a better suggestion, I intend to implement an “Execution” as a top-level FIXML ApplicationMessage. I will base the Execution on ExecutionReport but will remove those elements that are not relevant to an Execution (e.g. LeavesQty) and add elements that are required (e.g. LocalGrossPx, LocalNetPx, TradingBook)
> >
> > Any suggestions greatly appreciated.
> >
> > Ian Relf
> >
> >
> >
>
Thank you for your interest and prompt response.
As you say there are two possible approaches:
- Modify ExecutionReport to add a few extra fields and make optional some other fields, or
- Create a new group Trade Report with the extra fields and some fields from ExecutionReport
Either approach would suit my purposes I cannot say which is the correct approach; that is a decision for the committee.
I would comment that the latter would be a "purer" approach but probably less convenient. ExecutionReport already contains Order information for convenience, why not just add the extra information for Executions?
The elements that I require to be included in the new Trade Report group fall into four categories:
- Market Side Executions
Execution info - necessary to support market side executions - Internal Processing (Generic)
Execution info - necessary for any company implementing internal processing (e.g. passing from Front Office to Middle Office) - Internal Processing (Specific)
Execution info - necessary for the specific way that internal processing is implemented in HSBC - Convenience
Non-execution info, e.g. Order info – included for ease of use
Below is a list of new elements that I have specified for the new "Trade Report" group, complete with brief description.
I have broken them down into the four categories defined above:
-
Market Side Executions
Exchange Trade ID
This is a unique code that identifies this trade. It is issued by a stock exchange for trades at that stock exchange.
Dealt Exchange
Refers to the Stock Exchange that the trade was executed on e.g. L, N for LSE, NYSE
Settlement Clearing Location
The place where the trade actually gets settled, as opposed to dealt, e.g. Crest, Euroclear -
Internal Processing (Generic)
Executed By ID
Person in trading organisation that executed the trade.
Trade Flags
List of codes that refer to details about the trade being executed.
Trade Book
Refers to the book being used for this trade. -
Internal Processing (Specific)
Contracting Comp ID
Company that is handling this trade.
Version
The version number of this execution.
Local Net Price
The price of stock after the market side charges have been added.
Average Net Price
Average of all the net prices that have been used to fill this order.
Instrument List
A list of aliases for the instrument that is being traded, e.g. if instrument is referred to as an ISIN code, the instrument list may contain equivalent RIC and SEDOL codes. Also, it will be used to hold an instrument that gives the country that the instrument is registered in. -
Convenience
Originating Comp ID
The client’s primary interface to the trading organisation. This may not be the organisation through which the order was placed.
Order Created By
The person who created the order.
Order Notes
Notes referring to specific details about the order.
I believe that this is all that is required to represent an execution but other people may well suggest other fields.
Kind regards,
Ian Relf
One challenge with this discussion is that we have and are using common terminology with different meanings/perspectives. From my standpoint (buyside firm communicating with sellside firms), FIX most certainly supports “executions” (fills) and provides much more than status. It is very important that the overall order status is also provided with the details of “fills” (or the typical buyside-sellside definition of “execution”). FIX does not support “market side executions” or “street side trade reporting” today and that is what Dwight’s group is proposing.
The Execution Report message does serve multiple purposes, all of which are primarily as a response to orders. Today the Execution Report message provides the following functions (note list taken from FIX 4.2 spec’s Execution Report definition):
- confirm the receipt of an order
- confirm changes to an existing order (i.e. accept cancel and replace requests)
- relay order status information
- relay fill information on working orders
- reject orders
- report post-trade fees calculations associated with a trade
We are evaluating and discussion options regarding the best way for FIX 4.3 to support the requirements of "street side trade reporting" in which extending the Execution Report message may not be the best approach.
> Thank you for your interest and prompt response.
>
> As you say there are two possible approaches:
> 1. Modify ExecutionReport to add a few extra fields and make optional some other fields, or
> 2. Create a new group Trade Report with the extra fields and some fields from ExecutionReport
> Either approach would suit my purposes I cannot say which is the correct approach; that is a decision for the committee.
>
> I would comment that the latter would be a "purer" approach but probably less convenient. ExecutionReport already contains Order information for convenience, why not just add the extra information for Executions?
>
> The elements that I require to be included in the new Trade Report group fall into four categories:
> 1) Market Side Executions
> Execution info - necessary to support market side executions
> 2) Internal Processing (Generic)
> Execution info - necessary for any company implementing internal processing (e.g. passing from Front Office to Middle Office)
> 3) Internal Processing (Specific)
> Execution info - necessary for the specific way that internal processing is implemented in HSBC
> 4) Convenience
> Non-execution info, e.g. Order info – included for ease of use
>
> Below is a list of new elements that I have specified for the new "Trade Report" group, complete with brief description.
> I have broken them down into the four categories defined above:
>
> 1. Market Side Executions
> Exchange Trade ID
> This is a unique code that identifies this trade. It is issued by a stock exchange for trades at that stock exchange.
> Dealt Exchange
> Refers to the Stock Exchange that the trade was executed on e.g. L, N for LSE, NYSE
> Settlement Clearing Location
> The place where the trade actually gets settled, as opposed to dealt, e.g. Crest, Euroclear
>
> 2. Internal Processing (Generic)
> Executed By ID
> Person in trading organisation that executed the trade.
> Trade Flags
> List of codes that refer to details about the trade being executed.
> Trade Book
> Refers to the book being used for this trade.
>
> 3. Internal Processing (Specific)
> Contracting Comp ID
> Company that is handling this trade.
> Version
> The version number of this execution.
> Local Net Price
> The price of stock after the market side charges have been added.
> Average Net Price
> Average of all the net prices that have been used to fill this order.
> Instrument List
> A list of aliases for the instrument that is being traded, e.g. if instrument is referred to as an ISIN code, the instrument list may contain equivalent RIC and SEDOL codes. Also, it will be used to hold an instrument that gives the country that the instrument is registered in.
>
> 4. Convenience
> Originating Comp ID
> The client’s primary interface to the trading organisation. This may not be the organisation through which the order was placed.
> Order Created By
> The person who created the order.
> Order Notes
> Notes referring to specific details about the order.
>
>
>
>
> I believe that this is all that is required to represent an execution but other people may well suggest other fields.
>
> Kind regards,
> Ian Relf
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I’d like to address a few of these points.
> 1. Modify ExecutionReport to add a few extra fields and make optional some other fields, or
> 2. Create a new group Trade Report with the extra fields and some fields from ExecutionReport
> Either approach would suit my purposes I cannot say which is the correct approach; that is a decision for the committee.
First, the FIX Execution Report message is not necessarily the best name. Historically, that one message has been used to relay pretty much all info in response to an order, such as when the order is live, when trades happen against it, when it is cancelled, etc. Fields which are not needed for trades (i.e. LastShares, LastPx) are set to 0 in other messages. Separating the functionality of Execution Report for run-of-the-mill order flow would likely be a very significant change that would break a whole lot of stuff.
Execution reports are also used for one-way execution reports. I.e. an institution may have a proprietary terminal for an ECN, place orders that way, and the fills get reported via FIX electronically into their back office systems.
What Dwight is talking about is a very specific application that Execution Report does not fill well. That is for reporting “matched trades”. For instance, NYSE has to submit to DTCC the trades executed, as well as the parties involved in those trades. These are not one-sided execution reports (i.e. “You just bought 1000 IBM at 54”) but two-sided (i.e. "1000 IBM was traded at 54; the buyer was GSCO, the seller MLCO.) At present, the FIX Execution Report is poorly suited to this, and the going line of though now is to create a new message like an Execution Report with many critical fields duplicated, i.e. one could say BuyerExecBroker=GSCO, SellerExecBroker=MLCO. My guess is that this message is going to be of a very limited scope, so I’m not sure how applicable it will be for most firms.
> 1. Market Side Executions
> Exchange Trade ID
This sounds like a pretty good idea, although it may represented in a more general way. We have the concept of "SecondaryOrderID" on the Execution Report, which is generally what the stock exchange assigns to the order. Hence calling this "SecondaryExecID" instead could be useful, as then one could identify any ID an exchange gives for things like order acks, cancel acks, etc.
> Dealt Exchange
> Refers to the Stock Exchange that the trade was executed on e.g. L, N for LSE, NYSE
This exists and has been in the spec for years. It is called LastMkt. It requires Reuters codes (or the integer codes FPL assigns for exchanges / ECNs / ATSs without Reuters codes.
> 2. Internal Processing (Generic)
> Executed By ID
> Person in trading organisation that executed the trade.
I believe there is talk for 4.3 of adding a “TraderID” field to the Order message. I presume it could be added to the Execution Report as well. One would need to be careful to define whether it is the echoed-back value of what the client sends (which doesn’t meet this need), or if it is the trader handling the order (which makes a lot of sense.)
Also, the other party you traded with already exists in 4.2; it is called ContraTrader.
> Version
> The version number of this execution.
Is that necessary? Each ExecRpt has a unique ExecID, which you can use to reference the execution, and to bust/cancel it or correct it.
> Instrument List
> A list of aliases for the instrument that is being traded, e.g. if instrument is referred to as an ISIN code, the instrument list may contain equivalent RIC and SEDOL codes. Also, it will be used to hold an instrument that gives the country that the instrument is registered in.
I’m glad you posted this, as this seems to be a really hot topic recently. Dwight has made a somewhat controversial proposal to make SecurityID and IDSource part of a repeating group in the standard symbology block. A compromise proposal (which seems to be what you describe) was to add an optional block of additional identifiers for the instrument.
One side maintains that this is beneficial as it provides more potential to error check, and makes STP easier by giving people more of a choice of what symbology to use.
The other side maintains that this significantly complicates the spec, breaks existing implementations with new functionality, and introduces complexity since you must decide what to do if someone hands you a CUSIP and a SEDOL and you believe the two represent different instruments.
I’m interested in people’s thoughts regarding this.
> Order Created By
> The person who created the order.
This could be addressed by the proposal I believe is on the table to add TraderID to the Order message.
> Order Notes
> Notes referring to specific details about the order.
We have a generic Text field (and EncodedText for non-latin character sets.) Is this sufficient?
[ original email was from Tim Miller - timothy.miller@bankofamerica.com ]
I would like to use FIX to report trades in the way described by Ryan Pierce below:
>Execution reports are also used for one-way execution reports. I.e. an institution may have a proprietary terminal for an ECN, place orders that way, and the fills get reported via FIX electronically into their back office systems.
I have attempted to list below the fields which exist in FIX4.2 or are proposed in the "FIX Messaging for Fixed Income" (FIX 4.3) document and their semantic equivalents from the email sent by Ian Relf (HSBC) compared with the terminology in use on our systems (BOA). This is by no means definitive since we use several systems and the terminology can differ across those systems.
The BOA fields that I have listed are those we use to describe European Repo Trades. There are several new fields which would be required and I have put an asterix by those which could be viewed as more closely related to Back Office implementation rather than general Repo terminology. Like Ian, I would like to aim for a FIX protocol which can achieve STP by speaking from the Front to the Back Office. So although the asterixed fields could be optional it would seem that each company would require several "free text" fields to provide enough details.
SecondaryOrderID (FIX4.2) = ExchangeTradeID (HSBC) = TradeNumber (BOA) = SecondaryExecID / SecondaryTradeID?
LastMkt (FIX4.2) = DealtExchange (HSBC) = Market?
ContraBroker (FIX4.2) = Counterparty (BOA)
Text (FIX4.2) = OrderNotes (HSBC)
TraderID (FIX 4.3)(BOA) = OrderCreatedBy (HSBC)
SettlementDate (FIX4.3) = StartDate (BOA)
RepurchasePrice (FIX4.3) = RepoRate (BOA)
TradeBook (HSBC) = Book (BOA)
*TradeFlags (HSBC) =? BargainConditions (BOA)
NominalValue (BOA)
*Entity (BOA)
*CollateralDescriptor (BOA)
DaysBasis (BOA)
RateType (BOA)
*SettlementType (BOA)
Margin (BOA)
ContractingCompID (HSBC)
*Version (HSBC)
LocalNetPrice (HSBC)
AverageNetPrice (HSBC)
InstrumentList (HSBC)
OriginatingCompID (HSBC)
I would personally prefer to see new messages such as "TradeReport", or even "RepoTradeReport", since I think it would be cleaner and better defined than extending an "ExecutionReport" which has some fields relating to orders and some fields related to trades.
I’ve just a couple of comments on Tim’s mappings.
>
> SecondaryOrderID (FIX4.2) = ExchangeTradeID (HSBC) = TradeNumber (BOA) = SecondaryExecID / SecondaryTradeID?
Not quite.
A SecondaryOrderID is not equivalent to the others. The others do look equivalent.
A Secondary Order ID is an identifier generated by the secondary organisation, for example, an exchange/ECN. However, the order may be broken up into several executions. Each of these executions would be given its own identifier by the exchange/ECN, a Secondary Exec ID; all of these executions would refer to the same Secondary Order ID.
Any one of the above names should suffice. However, I think that SecondaryExecID looks the most suitable (FIX compliant).
> LastMkt (FIX4.2) = DealtExchange (HSBC) = Market?
Fine.
> Text (FIX4.2) = OrderNotes (HSBC)
Well, sort of but I’ve already used Text for the more appropriate ExecutionNotes.
>
> TraderID (FIX 4.3)(BOA) = OrderCreatedBy (HSBC)
May I suggest that:
Order/TraderID = OrderCreatedByID
ExecutionReport/TraderID = ExecutedByID (HSBC)
So, adding TraderID to ExecutionReport can only satisfy one HSBC required field.
> First, the FIX Execution Report message is not necessarily the best name. Historically, that one message has been used to relay pretty much all info in response to an order, such as when the order is live, when trades happen against it, when it is cancelled, etc. Fields which are not needed for trades (i.e. LastShares, LastPx) are set to 0 in other messages. Separating the functionality of Execution Report for run-of-the-mill order flow would likely be a very significant change that would break a whole lot of stuff.
Yes, Execution Report is a bit of a misnomer - Order Status Report may be more suitable.
I would imagine that renaming and/or separating out functionality would affect too many existing systems to be feasible. Moreover, even though one may take the moral high ground of a purer message by removing the stuff that does not "belong" in the message; it is (presumably) there for convenience so, from a pragmatic perspective, it would be better to leave it in.
So, the jury is still out as to whether we should extend Execution Report or create a new Trade Report.
>
> > 1. Market Side Executions
> > Exchange Trade ID
>
> This sounds like a pretty good idea, although it may represented in a more general way. We have the concept of "SecondaryOrderID" on the Execution Report, which is generally what the stock exchange assigns to the order. Hence calling this "SecondaryExecID" instead could be useful, as then one could identify any ID an exchange gives for things like order acks, cancel acks, etc.
Renaming Exchange Trade ID to Secondary Exec ID does seem to be more in keeping with current FIX parlance.
>
> > Dealt Exchange
> > Refers to the Stock Exchange that the trade was executed on e.g. L, N for LSE, NYSE
>
> This exists and has been in the spec for years. It is called LastMkt. It requires Reuters codes (or the integer codes FPL assigns for exchanges / ECNs / ATSs without Reuters codes.
LastMkt – yes, that is what we want.
>
> > 2. Internal Processing (Generic)
> > Executed By ID
> > Person in trading organisation that executed the trade.
>
> I believe there is talk for 4.3 of adding a “TraderID” field to the Order message. I presume it could be added to the Execution Report as well. One would need to be careful to define whether it is the echoed-back value of what the client sends (which doesn’t meet this need), or if it is the trader handling the order (which makes a lot of sense.)
>
> Also, the other party you traded with already exists in 4.2; it is called ContraTrader.
Adding Trader ID to ExecRep should do the trick.
>
> > Version
> > The version number of this execution.
>
> Is that necessary? Each ExecRpt has a unique ExecID, which you can use to reference the execution, and to bust/cancel it or correct it.
Yes. We could simply add a ".<VersionNumber>" on to the end of the Exec ID.
>
> > Instrument List
> > A list of aliases for the instrument that is being traded, e.g. if instrument is referred to as an ISIN code, the instrument list may contain equivalent RIC and SEDOL codes. Also, it will be used to hold an instrument that gives the country that the instrument is registered in.
>
> I’m glad you posted this, as this seems to be a really hot topic recently. Dwight has made a somewhat controversial proposal to make SecurityID and IDSource part of a repeating group in the standard symbology block. A compromise proposal (which seems to be what you describe) was to add an optional block of additional identifiers for the instrument.
>
> One side maintains that this is beneficial as it provides more potential to error check, and makes STP easier by giving people more of a choice of what symbology to use.
>
> The other side maintains that this significantly complicates the spec, breaks existing implementations with new functionality, and introduces complexity since you must decide what to do if someone hands you a CUSIP and a SEDOL and you believe the two represent different instruments.
>
> I’m interested in people’s thoughts regarding this.
Changing Instrument to InstrumentList:
- Will provide extra symbols to choose from,
- Will break implementations,
- Will introduce ambiguities if two non-equivalent codes are provided.
However, introducing an optional InstrumentList, in addition to keeping the original Instrument:
- Will still have the benefit of providing a choice of symbols,
- Will not break implementations (Instrument is still present),
- Will not introduce (unresolvable) ambiguities – discrepancies between non-equivalent codes can be arbitrated by the Instrument code.
>
> > Order Created By
> > The person who created the order.
>
> This could be addressed by the proposal I believe is on the table to add TraderID to the Order message.
Yes, that would cover the required information but for convenience it would be useful to include this information in ExecRep.
>
> > Order Notes
> > Notes referring to specific details about the order.
>
> We have a generic Text field (and EncodedText for non-latin character sets.) Is this sufficient?
>
Well…
A text field would be sufficient but the problem is that we want to store both Execution Notes AND Order Notes.
Obviously this is another example of wanting to include, for convenience, elements that actually belong to another message.
I have considered putting both sets of notes into the same text field, delimited by "EXECUTION_NOTES" and "ORDER_NOTES" but it does seem a little messy and introduces another parsing overhead for the client.
Perhaps ExecRep could support a TextList field that had a data type enumerator (similar to IDSource). This would allow one Text of type Execution Notes and another Text of type Order Notes.
[ original email was from Jack Smith - jack.smith@csfb.com ]
’…Separating the functionality of Execution Report for run-of-the-mill order flow would likely be a very significant change that would break a whole lot of stuff…’
‘…removing the stuff that does not “belong” in the message; it is (presumably) there for convenience so, from a pragmatic perspective, it would be better to leave it in…’
Please do not remove information from the Execution Report (or new ‘TRADE’ report message).
One of the biggest problems we face is the fact that upon receipt of any message we invariably have to make a database call to resolve unknown information. When dealing with very high volumns this is a major performance hit.
I agree with creating a new message type, since my impression of FIX has changed over time from thinking that it was very well though out and complete to feeling that it is actually very sloppy.
The categorization of fields into required/not required needs re-working. as well as the description of the fields.
Example:
What is the difference between ExecTransType and ExecType and how are they used together.
If I am reporting a new execution which fully satisfies an order, what value do I enter for ExecType ? 0=New, 2=Fill, or A=Pending New.
When do I use SymbolSfx vs SecurityType ? Clearly they are hardly any different since the description for SymbolSfx says ‘…Note also see SecurityType…’
What about SettlmentType, where is a value for T+3, a very common settlement period indeed.
The descriptions for LastShares and LastPx are muddled and difficult to interpret.