Imported from previous forum
If we send an order that can last for mutliple days (GTC, etc.), what should we expect to be the proper flow of executions and allocations? It seems on a day order we would wait till the order is completely filled and then send an allocation, but what about multi-day orders? Should we (must we?) send an allocation at the end of every day covering the executions from that day?
These questions have to do with us determining our database structure. Do people generally go to full generality and make a database table for allocation messages with a many-to-many mapping to orders? (using an intersect table…) This would seem necessary if an allocation was used at the end of every day in a multi-day order…
> If we send an order that can last for mutliple days (GTC, etc.), what should we expect to be the proper flow of executions and allocations? It seems on a day order we would wait till the order is completely filled and then send an allocation, but what about multi-day orders? Should we (must we?) send an allocation at the end of every day covering the executions from that day?
>
> These questions have to do with us determining our database structure. Do people generally go to full generality and make a database table for allocation messages with a many-to-many mapping to orders? (using an intersect table…) This would seem necessary if an allocation was used at the end of every day in a multi-day order…
>
On a multi-day order you should assume that you will need to be able to process allocations on each day that there is an executed quantity to be booked out. It is possible that the executions will be booked out at the end of the order (e.g. when it is fully filled or expired), but this is not general practice in most markets.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> On a multi-day order you should assume that you will need to be able to process allocations on each day that there is an executed quantity to be booked out. It is possible that the executions will be booked out at the end of the order (e.g. when it is fully filled or expired), but this is not general practice in most markets.
To further clarify, in the odd cases where trades for GT orders should be warehoused and booked won the day the order fills or is cancelled, the field GTBookingInst would be used to indicate this.
Ok, so if we’re allocating at the end of each day for a multi-day GT order, does that mean that the executions that are being allocated need to be specified in the allocation messages? Or do we just need to make sure the Quantity and AvgPx are the DayCumQty and DayAvgPx from the last execution of the day?
> > If we send an order that can last for mutliple days (GTC, etc.), what should we expect to be the proper flow of executions and allocations? It seems on a day order we would wait till the order is completely filled and then send an allocation, but what about multi-day orders? Should we (must we?) send an allocation at the end of every day covering the executions from that day?
> >
> > These questions have to do with us determining our database structure. Do people generally go to full generality and make a database table for allocation messages with a many-to-many mapping to orders? (using an intersect table…) This would seem necessary if an allocation was used at the end of every day in a multi-day order…
> >
> On a multi-day order you should assume that you will need to be able to process allocations on each day that there is an executed quantity to be booked out. It is possible that the executions will be booked out at the end of the order (e.g. when it is fully filled or expired), but this is not general practice in most markets.
>
First off you can allocate at the execution level or the block level (across a number of executions)according to market practise. In European equities the common practise is to communicate allocations at the block (order) level. If you are allocating at the block level you do not need to specify the individual executions on the allocation message
If on a GT order you book out each day using a single allocation message then, yes, the AvgPx and the quantity on the allocation message would be set to the total executed quantity for the day and the average price for that day
> Ok, so if we’re allocating at the end of each day for a multi-day GT order, does that mean that the executions that are being allocated need to be specified in the allocation messages? Or do we just need to make sure the Quantity and AvgPx are the DayCumQty and DayAvgPx from the last execution of the day?
>
>
>
> > > If we send an order that can last for mutliple days (GTC, etc.), what should we expect to be the proper flow of executions and allocations? It seems on a day order we would wait till the order is completely filled and then send an allocation, but what about multi-day orders? Should we (must we?) send an allocation at the end of every day covering the executions from that day?
> > >
> > > These questions have to do with us determining our database structure. Do people generally go to full generality and make a database table for allocation messages with a many-to-many mapping to orders? (using an intersect table…) This would seem necessary if an allocation was used at the end of every day in a multi-day order…
> > >
> > On a multi-day order you should assume that you will need to be able to process allocations on each day that there is an executed quantity to be booked out. It is possible that the executions will be booked out at the end of the order (e.g. when it is fully filled or expired), but this is not general practice in most markets.
> >
>
Thanks. One other question. If it is the second day on a GT order and I want to allocate the executions for the day, do I need to specify the day’s executions in the execution repeating block of the allocation message or can I just specify the order and assume that the sell-side understands I mean the part of the order that was not already allocated. (that is, the part not allocated yesterday…)
> First off you can allocate at the execution level or the block level (across a number of executions)according to market practise. In European equities the common practise is to communicate allocations at the block (order) level. If you are allocating at the block level you do not need to specify the individual executions on the allocation message
>
> If on a GT order you book out each day using a single allocation message then, yes, the AvgPx and the quantity on the allocation message would be set to the total executed quantity for the day and the average price for that day
>
>
>
> > Ok, so if we’re allocating at the end of each day for a multi-day GT order, does that mean that the executions that are being allocated need to be specified in the allocation messages? Or do we just need to make sure the Quantity and AvgPx are the DayCumQty and DayAvgPx from the last execution of the day?
> >
> >
> >
> > > > If we send an order that can last for mutliple days (GTC, etc.), what should we expect to be the proper flow of executions and allocations? It seems on a day order we would wait till the order is completely filled and then send an allocation, but what about multi-day orders? Should we (must we?) send an allocation at the end of every day covering the executions from that day?
> > > >
> > > > These questions have to do with us determining our database structure. Do people generally go to full generality and make a database table for allocation messages with a many-to-many mapping to orders? (using an intersect table…) This would seem necessary if an allocation was used at the end of every day in a multi-day order…
> > > >
> > > On a multi-day order you should assume that you will need to be able to process allocations on each day that there is an executed quantity to be booked out. It is possible that the executions will be booked out at the end of the order (e.g. when it is fully filled or expired), but this is not general practice in most markets.
> > >
> >
>