Imported from previous forum
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
I am trying to include some trade status information in the Trade Capture Report message, such as:
-
New Trade -
Corrected Trade -
Canceled Trade -
Allocation Pending -
Allocation Accepted -
Allocation Rejected
It seems that 1-3 can be easily handled by the ExecType tag. However, I do not see a straightforward way to convey the other statuses. Is there a another tag which may be use for 4-6? It seems that the situation calls for something similar to 'OrdStatus’for trades (‘TrdStatus’)?
Andre -
I see trade status and allocation status as two different concepts. I assume that by using ExecType you are trying to convey the trade status of the exection when post-trade reporting is performed. Allocation is a post-trade action that occurs using the Allocation workflow. The trade is referenced via an allocation which in turn has its own set of status’s inclusive of accepted, rejected and pending.
If the allocation workflow is not being used and the trade itself is being directly allocated using a trade claim mechansim then the TradeReportType provides the proper status’s. Normally, this type of flow is used in a private negotiation rather than with an electronically executed trade. See the Trade Capture section in Vol 5 of 5.0 SP1.
I am trying to include some trade status information in the Trade
Capture Report message, such as:
New TradeCorrected TradeCanceled TradeAllocation PendingAllocation AcceptedAllocation RejectedIt seems that 1-3 can be easily handled by the ExecType tag. However, I
do not see a straightforward way to convey the other statuses. Is there
a another tag which may be use for 4-6? It seems that the situation
calls for something similar to 'OrdStatus’for trades (‘TrdStatus’)?
Allocation is a post trade activity.
So for 4-6, MsgType P (Allocation ACK) should be used with the suitable value in Tag#87 (Allocation Status) and Tag#88 (allocation Reject code).
In MsgType P there no is ExecType. Hence Trade Status and Alocation Status is different.
Amiya.
Andre - I see trade status and allocation status as two different
concepts. I assume that by using ExecType you are trying to convey the
trade status of the exection when post-trade reporting is performed.
Allocation is a post-trade action that occurs using the Allocation
workflow. The trade is referenced via an allocation which in turn has
its own set of status’s inclusive of accepted, rejected and pending.If the allocation workflow is not being used and the trade itself is
being directly allocated using a trade claim mechansim then the
TradeReportType provides the proper status’s. Normally, this type of
flow is used in a private negotiation rather than with an electronically
executed trade. See the Trade Capture section in Vol 5 of 5.0 SP1.I am trying to include some trade status information in the Trade
Capture Report message, such as:
New TradeCorrected TradeCanceled TradeAllocation PendingAllocation AcceptedAllocation RejectedIt seems that 1-3 can be easily handled by the ExecType tag. However,
I do not see a straightforward way to convey the other statuses. Is
there a another tag which may be use for 4-6? It seems that the
situation calls for something similar to 'OrdStatus’for trades
(‘TrdStatus’)?
[ original email was from John Harris - john.harris@bondmart.com ]
I hope that at some point in the not-to-distant future, the FIX Protocol reflects the reality of allocation, which is that it is properly a pre-trade activity.
No manager of multiple accounts should ever submit a block order (and hence obtain an execution of that block order) without knowing before the fact the apportionment of that order among the accounts legally or contractually responsible for it.
Those details should be submitted with the order, so that the contra principals are known to one another prior to execution.
For too long in the voice world, market practice tolerated the absurd situation of agents (money managers) executing trades without giving up their principals in advance. In order for such practice to be tolerable from a legal or risk-management perspective, any such executions should have been deemed subject to cancellation, pending disclosure of principals.
No excuse exists for the continuation of that practice in the electronic-execution world, especially in this day and age. Money managers are duty bound to know the constituents of their block orders. The FIX protocol provides the means for them to identify those constituents at the pregnant moment. The next step in the evolution of the protocol should be that allocation of block orders is required.
Certainly the protocol should allow for post-trade correction of allocations - mistakes will be made - but the time has passed for initial allocations of block trades to be made on a post-trade basis.
Allocation is a post trade activity. So for 4-6, MsgType P (Allocation
ACK) should be used with the suitable value in Tag#87 (Allocation
Status) and Tag#88 (allocation Reject code). In MsgType P there no is
ExecType. Hence Trade Status and Alocation Status is different.Amiya.
Andre - I see trade status and allocation status as two different
concepts. I assume that by using ExecType you are trying to convey the
trade status of the exection when post-trade reporting is performed.
Allocation is a post-trade action that occurs using the Allocation
workflow. The trade is referenced via an allocation which in turn has
its own set of status’s inclusive of accepted, rejected and pending.If the allocation workflow is not being used and the trade itself is
being directly allocated using a trade claim mechansim then the
TradeReportType provides the proper status’s. Normally, this type of
flow is used in a private negotiation rather than with an
electronically executed trade. See the Trade Capture section in Vol 5
of 5.0 SP1.I am trying to include some trade status information in the Trade
Capture Report message, such as:
New TradeCorrected TradeCanceled TradeAllocation PendingAllocation AcceptedAllocation RejectedIt seems that 1-3 can be easily handled by the ExecType tag.
However, I do not see a straightforward way to convey the other
statuses. Is there a another tag which may be use for 4-6? It seems
that the situation calls for something similar to 'OrdStatus’for
trades (‘TrdStatus’)?
[ original email was from Marcio Castro - mcastro@bmf.com.br ]
John,
I completely agree with you in terms of how allocation should be processed.
But I believe the support for this is already on FIX Protocol.
In the NewOrderSingle message you have the AllocId, which ties to the AllocationInstruction message.
AllocationInstruction message has NoAllocs repeating group that allows you to represent every account/end client participating in the block order/trade.
Although AllocationInstruction is classified as Post Trade, nothing would prevent one to send this altogether with NewOrderSingle.
Regards,
Marcio Castro.
I hope that at some point in the not-to-distant future, the FIX Protocol
reflects the reality of allocation, which is that it is properly a pre-
trade activity.No manager of multiple accounts should ever submit a block order (and
hence obtain an execution of that block order) without knowing before
the fact the apportionment of that order among the accounts legally or
contractually responsible for it.Those details should be submitted with the order, so that the contra
principals are known to one another prior to execution.For too long in the voice world, market practice tolerated the absurd
situation of agents (money managers) executing trades without giving up
their principals in advance. In order for such practice to be tolerable
from a legal or risk-management perspective, any such executions should
have been deemed subject to cancellation, pending disclosure of
principals.No excuse exists for the continuation of that practice in the electronic-
execution world, especially in this day and age. Money managers are duty
bound to know the constituents of their block orders. The FIX protocol
provides the means for them to identify those constituents at the
pregnant moment. The next step in the evolution of the protocol should
be that allocation of block orders is required.Certainly the protocol should allow for post-trade correction of
allocations - mistakes will be made - but the time has passed for
initial allocations of block trades to be made on a post-trade basis.Allocation is a post trade activity. So for 4-6, MsgType P (Allocation
ACK) should be used with the suitable value in Tag#87 (Allocation
Status) and Tag#88 (allocation Reject code). In MsgType P there no is
ExecType. Hence Trade Status and Alocation Status is different.Amiya.
Andre - I see trade status and allocation status as two different
concepts. I assume that by using ExecType you are trying to convey
the trade status of the exection when post-trade reporting is
performed. Allocation is a post-trade action that occurs using the
Allocation workflow. The trade is referenced via an allocation which
in turn has its own set of status’s inclusive of accepted, rejected
and pending.If the allocation workflow is not being used and the trade itself is
being directly allocated using a trade claim mechansim then the
TradeReportType provides the proper status’s. Normally, this type of
flow is used in a private negotiation rather than with an
electronically executed trade. See the Trade Capture section in Vol
5 of 5.0 SP1.I am trying to include some trade status information in the Trade
Capture Report message, such as:
New TradeCorrected TradeCanceled TradeAllocation PendingAllocation AcceptedAllocation RejectedIt seems that 1-3 can be easily handled by the ExecType tag.
However, I do not see a straightforward way to convey the other
statuses. Is there a another tag which may be use for 4-6? It
seems that the situation calls for something similar to
'OrdStatus’for trades (‘TrdStatus’)?
[ original email was from John Harris - john.harris@bondmart.com ]
Marcio, I agree with you, as well. I am simply proposing that at some future date, the protocol make pre-trade allocations required - not optional - for block trades. Let’s have the protocol, in other words, enforce the proper business practice and not merely support it.
John, I completely agree with you in terms of how allocation should be
processed.But I believe the support for this is already on FIX Protocol. In the
NewOrderSingle message you have the AllocId, which ties to the
AllocationInstruction message.AllocationInstruction message has NoAllocs repeating group that allows
you to represent every account/end client participating in the block
order/trade.Although AllocationInstruction is classified as Post Trade, nothing
would prevent one to send this altogether with NewOrderSingle.Regards,
Marcio Castro.
I hope that at some point in the not-to-distant future, the FIX
Protocol reflects the reality of allocation, which is that it is
properly a pre- trade activity.No manager of multiple accounts should ever submit a block order (and
hence obtain an execution of that block order) without knowing before
the fact the apportionment of that order among the accounts legally or
contractually responsible for it.Those details should be submitted with the order, so that the contra
principals are known to one another prior to execution.For too long in the voice world, market practice tolerated the absurd
situation of agents (money managers) executing trades without giving
up their principals in advance. In order for such practice to be
tolerable from a legal or risk-management perspective, any such
executions should have been deemed subject to cancellation, pending
disclosure of principals.No excuse exists for the continuation of that practice in the electronic-
execution world, especially in this day and age. Money managers are
duty bound to know the constituents of their block orders. The FIX
protocol provides the means for them to identify those constituents at
the pregnant moment. The next step in the evolution of the protocol
should be that allocation of block orders is required.Certainly the protocol should allow for post-trade correction of
allocations - mistakes will be made - but the time has passed for
initial allocations of block trades to be made on a post-trade basis.Allocation is a post trade activity. So for 4-6, MsgType P
(Allocation ACK) should be used with the suitable value in Tag#87
(Allocation Status) and Tag#88 (allocation Reject code). In MsgType
P there no is ExecType. Hence Trade Status and Alocation Status is
different.Amiya.
Andre - I see trade status and allocation status as two different
concepts. I assume that by using ExecType you are trying to convey
the trade status of the exection when post-trade reporting is
performed. Allocation is a post-trade action that occurs using the
Allocation workflow. The trade is referenced via an allocation
which in turn has its own set of status’s inclusive of accepted,
rejected and pending.If the allocation workflow is not being used and the trade itself
is being directly allocated using a trade claim mechansim then the
TradeReportType provides the proper status’s. Normally, this type
of flow is used in a private negotiation rather than with an
electronically executed trade. See the Trade Capture section in
Vol 5 of 5.0 SP1.I am trying to include some trade status information in the
Trade Capture Report message, such as:
New TradeCorrected TradeCanceled TradeAllocation PendingAllocation AcceptedAllocation RejectedIt seems that 1-3 can be easily handled by the ExecType tag.
However, I do not see a straightforward way to convey the other
statuses. Is there a another tag which may be use for 4-6? It
seems that the situation calls for something similar to
'OrdStatus’for trades (‘TrdStatus’)?
[Start Quote from http://www.fixprotocol.org/pages/1448/matrix_def.htm#_Allocations]
Allocations
Allocations can be performed both pre- or post-trade. Post trade allocations are supported in the form of a separate FIX message type, whilst pre-trade allocation is achieved by sending allocation details on the order message itself.
Pre-allocation functionality was not introduced until FIX 4.2. Pre-trade allocation is much more commonplace in the program trading community than it is in block trading hence the limited support indicated in the matrix.
For the purposes of pre-trade allocation, a repeating group covering account and number of shares was added to the order message in 4.2.
Cross border allocations support was introduced in version 4.1, as was support for allocating Futures & Options trades. Support for Fixed Income was introduced from version 4.3 of the protocol onwards.
FIX 4.4 saw the introduction of a common allocation model across multiple asset classes for both cash and listed derivatives instruments. This work is on-going driven by the FIX Allocation Working Group and the FIA Extensions for Clearing Working Group.
In FIX 5.0, the Allocations for Options Extension provides the ability to represent the open or close disposition of a trade or position on both the give-up and carry firm side of the allocation.
[End Quote]
No manager of multiple accounts should ever submit a block order
(and hence obtain an execution of that block order) without knowing
before the fact the apportionment of that order among the accounts
legally or contractually responsible for it.
Question : What differentiates a block trade from a non-block trade in FIX? I do not see any tag in New Order Single ^35=D^ which differentiates a block trade.
[Start Quote from Block Trade: Definition, How It Works, and Example]
In general, 10,000 shares of stock (not including penny stocks) or $200,000 worth of bonds would be considered a block trade.
[End Quote]
[Start Quote from Block trade - Wikipedia]
…It can also refer specifically to large trades that occur between institutional parties at a fixed price. For instance, an insurance company may hold a large stake in a company that they would like to liquidate completely. If this were put into the market as a large sell order, the price would sharply drop — by definition, the stake was large enough to affect supply and demand…
[End Quote]
So should Allocation instructions be made mandatory for Orders which exceed the above mentioned size limits? or only when institutional parties are involved in a large trade? Or should a new boolean FIX Tag be introduced like “IsBlock” with values Yes / No be introduced, the absence of this Tag meaning No and Securities & Exchange Commision introducing rules forcing Block Trades to be identified as such?
[ original email was from John Harris - john.harris@bondmart.com ]
Excellent post, Mahesh.
I am aware that some exchanges and dictionaries define block trades in terms of size. Such definitions are absurd. A block trade is a trade executed on behalf of two or more legal entities (“accounts”).
That said, I do not believe that FIX needs a block-related tag, because “blockiness” can be inferred from other order details. If an order (or trade) is allocated to more than one account, it is a block order (or trade). Similarly, for those (silly) venues who prefer to define blockiness in terms of size, if an order (or trade) meets or exceeds the arbitrary size threshold established by the venue, it is a block order (or trade).
If it can be done without creating unnecessary message bloat or changing the protocol for light reasons, I would favor defining “allocation” for FIX purposes as “the act of assigning ownership of an order to at least one legal entity.” Thus, every order would be an allocated order and with respect to allocations, the only differences among orders would be “how many” and “to which accounts.”
[Start Quote from
http://www.fixprotocol.org/pages/1448/matrix_def.htm#_Allocations]Allocations
Allocations can be performed both pre- or post-trade. Post trade
allocations are supported in the form of a separate FIX message type,
whilst pre-trade allocation is achieved by sending allocation details on
the order message itself.Pre-allocation functionality was not introduced until FIX 4.2. Pre-
trade allocation is much more commonplace in the program trading
community than it is in block trading hence the limited support
indicated in the matrix.For the purposes of pre-trade allocation, a repeating group covering
account and number of shares was added to the order message in 4.2.Cross border allocations support was introduced in version 4.1, as was
support for allocating Futures & Options trades. Support for Fixed
Income was introduced from version 4.3 of the protocol onwards.FIX 4.4 saw the introduction of a common allocation model across
multiple asset classes for both cash and listed derivatives instruments.
This work is on-going driven by the FIX Allocation Working Group and the
FIA Extensions for Clearing Working Group.In FIX 5.0, the Allocations for Options Extension provides the ability
to represent the open or close disposition of a trade or position on
both the give-up and carry firm side of the allocation.[End Quote]
No manager of multiple accounts should ever submit a block order (and
hence obtain an execution of that block order) without knowing before
the fact the apportionment of that order among the accounts legally or
contractually responsible for it.Question : What differentiates a block trade from a non-block trade in
FIX? I do not see any tag in New Order Single ^35=D^ which
differentiates a block trade.[Start Quote from Block Trade: Definition, How It Works, and Example]
In general, 10,000 shares of stock (not including penny stocks) or
$200,000 worth of bonds would be considered a block trade.[End Quote]
[Start Quote from Block trade - Wikipedia]
…It can also refer specifically to large trades that occur between
institutional parties at a fixed price. For instance, an insurance
company may hold a large stake in a company that they would like to
liquidate completely. If this were put into the market as a large sell
order, the price would sharply drop — by definition, the stake was
large enough to affect supply and demand…[End Quote]
So should Allocation instructions be made mandatory for Orders which
exceed the above mentioned size limits? or only when institutional
parties are involved in a large trade? Or should a new boolean FIX Tag
be introduced like “IsBlock” with values Yes / No be introduced, the
absence of this Tag meaning No and Securities & Exchange Commision
introducing rules forcing Block Trades to be identified as such?
[ original email was from Greg Wood - gregjwood@hotmail.com ]
Hi all,
I would agree with John in most aspects.
It is almost a certainty that a block trade is going to be split into multiple post-trade allocations. However there are several uses of the word “block” that can be potentially confusing.
From a pre-trade perspective, the majority of block trades are generated by aggregating individual orders to obtain a potentially better execution as a single block rather than as multiple individual orders. That’s not always true of course since a trader might have a very large position that they need to move and there is no aggregation of orders. Either could be executed as a single block (i.e. one trade at a single price) on an exchange or crossing network using pre-negotiation to arrange a price at the mid point of the prevailing market, or they might be traded using an execution algo that will manage the trading of the block into much smaller slices that roll up to a parent ticket that then has an average price. Exchanges usually set size requirements on block orders to limit the use of pre-negotiation rather than relying on natural price discovery within the marketplace.
Whilst it is a possibility that a block order could be pre-allocated, by far the most common workflow outside of systematic program trading is to allocate after the event. That’s common across most asset classes including Equities, Futures and FX.
In the post-trade world a trade or even a net position that needs to be split into 1 or more allocations is often referred to as a “block” even though the tickets making up the instructon may not have necessarily been executed as a physical block trade as described above.
“Blockiness” in this case is usually inferred by the trade(s) sitting within a holding account (aka suspense account, wait account, break account or just “allocation” account) at one legal entity, usually the executing broker. The orders specify the holding account at time of inception (or they default into that account) and a flag is raised within the back-office that the trades must be moved out of the holding account by means of an allocation instruction. That’s not necessarily a function of FIX.
The FIX allocation instruction does not need to explicitly state that a block is being allocated. As John says, this can be inferred from within the existing Allocation Instruction (MsgTye J), for example from the order details included. However I have found that the FAWG proposal does leave out a simple manner of identifying the holding account from each allocation block. Something to look at standardising later …
However with regards to pre-execution of a block trade, it would actually be nice to have a tag such as “IsBlock”. “IsBlock=Y” would allow easy routing of such orders to pre-negotiation mechanisms on exchanges and ECNs that support such functionality. That makes such execution easier to manage via FIX particularly when the sell-side still tends to rely on exchange terminals for this sort of thing. I’m against protocol bloat so this could possibly be included as an ExecInst value, or may be covered by the MsgType New Order - Cross. A cross is not necessarily a block or vice versa, but I’d be interested to see examples of this MsgType in practice since a lot of the workflow is similar such as the use of price discovery via an IOI.
Sorry for the long post, this is an interesting subject. Hope my input helps.
Regards,
- Greg
Excellent post, Mahesh.
I am aware that some exchanges and dictionaries define block trades in
terms of size. Such definitions are absurd. A block trade is a trade
executed on behalf of two or more legal entities (“accounts”).That said, I do not believe that FIX needs a block-related tag, because
“blockiness” can be inferred from other order details. If an order (or
trade) is allocated to more than one account, it is a block order (or
trade). Similarly, for those (silly) venues who prefer to define
blockiness in terms of size, if an order (or trade) meets or exceeds the
arbitrary size threshold established by the venue, it is a block order
(or trade).If it can be done without creating unnecessary message bloat or changing
the protocol for light reasons, I would favor defining “allocation” for
FIX purposes as “the act of assigning ownership of an order to at least
one legal entity.” Thus, every order would be an allocated order and
with respect to allocations, the only differences among orders would be
“how many” and “to which accounts.”[Start Quote from
http://www.fixprotocol.org/pages/1448/matrix_def.htm#_Allocations]Allocations
Allocations can be performed both pre- or post-trade. Post trade
allocations are supported in the form of a separate FIX message type,
whilst pre-trade allocation is achieved by sending allocation details
on the order message itself.Pre-allocation functionality was not introduced until FIX 4.2. Pre-
trade allocation is much more commonplace in the program trading
community than it is in block trading hence the limited support
indicated in the matrix.For the purposes of pre-trade allocation, a repeating group covering
account and number of shares was added to the order message in 4.2.Cross border allocations support was introduced in version 4.1, as was
support for allocating Futures & Options trades. Support for Fixed
Income was introduced from version 4.3 of the protocol onwards.FIX 4.4 saw the introduction of a common allocation model across
multiple asset classes for both cash and listed derivatives
instruments. This work is on-going driven by the FIX Allocation
Working Group and the FIA Extensions for Clearing Working Group.In FIX 5.0, the Allocations for Options Extension provides the ability
to represent the open or close disposition of a trade or position on
both the give-up and carry firm side of the allocation.[End Quote]
No manager of multiple accounts should ever submit a block order (and
hence obtain an execution of that block order) without knowing before
the fact the apportionment of that order among the accounts legally
or contractually responsible for it.Question : What differentiates a block trade from a non-block trade in
FIX? I do not see any tag in New Order Single ^35=D^ which
differentiates a block trade.[Start Quote from Block Trade: Definition, How It Works, and Example]
In general, 10,000 shares of stock (not including penny stocks) or
$200,000 worth of bonds would be considered a block trade.[End Quote]
[Start Quote from Block trade - Wikipedia]
…It can also refer specifically to large trades that occur between
institutional parties at a fixed price. For instance, an insurance
company may hold a large stake in a company that they would like to
liquidate completely. If this were put into the market as a large sell
order, the price would sharply drop — by definition, the stake was
large enough to affect supply and demand…[End Quote]
So should Allocation instructions be made mandatory for Orders which
exceed the above mentioned size limits? or only when institutional
parties are involved in a large trade? Or should a new boolean FIX Tag
be introduced like “IsBlock” with values Yes / No be introduced, the
absence of this Tag meaning No and Securities & Exchange Commision
introducing rules forcing Block Trades to be identified as such?