[This message was posted by Greg Wood of Credit Suisse <[email protected]>
to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You
can reply to it on-line at http://fixprotocol.org/discuss/read/dfa35b1f -
PLEASE DO NOT REPLY BY MAIL.]
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 http://www.investopedia.com/terms/b/blocktrade.asp]
> >
> > 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 http://en.wikipedia.org/wiki/Block_trade]
> >
> > ...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?
[You can unsubscribe from this discussion group by sending a message to
mailto:[email protected]]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
