LUSID's order management system includes out-of-the-box allocation algorithms available for use, allowing you to automatically allocate fills to portfolios from executions you've received back from brokers each day. Using allocation algorithms, LUSID can assist in end of day (EOD) processes such as highlighting any remaining allocations which have yet to be booked into a portfolio as a transaction.
When an execution is received, LUSID generates a new allocation based on your preferred algorithm and the block of orders the execution originated from. You can specify combinations of algorithms to define how daily fills are allocated, from base algorithms to how any leftovers are allocated. This page explains your options and how each algorithm works:
- Pro rata: Distributing allocations in equal portions
- Round robin: Distributing allocations cyclically
- Booking transactions
- Appendix A: Selecting allocation algorithm combinations
Pro rata: Distributing allocations in equal portions
LUSID's default allocation algorithm evenly distributes fills according to the size of the order. When an execution containing a number of fills is received, the pro rata algorithm decides the percentage of fills to allocate to each order from the block that was placed.
For each order, the number of fills yet to be received is divided by the total fills yet to be received for the block. This is then multiplied by the number of fills received in the execution to give the total number of fills allocated to each order:
Note: All decimals are rounded down to the nearest integer.
For example, imagine:
- You have created an order for 30 AAPL US equity shares.
- This order is placed in the market as part of a larger block of 100 AAPL US equity shares.
- You have received an execution of 40 shares.
LUSID uses its pro rata algorithm to allocate 12 of the shares from the execution to your order, with the rest distributed amongst other orders in the block:
With this algorithm, note:
- Orders cannot be allocated more fills than the quantity ordered.
- By default, any leftover fills (from rounding down decimals, for example) are allocated using a secondary ‘round robin’ algorithm with a first in, first out (FIFO) hierarchy (see the section below).
- If a second execution is received, all fills received so far but not yet booked as transactions (including fills from previous executions) are summed and reallocated using the selected algorithm (see the section below).
Round robin: Distributing allocations cyclically
You can also choose to use a round robin algorithm to allocate fills to orders. When an execution is received with this method, LUSID allocates one fill to each order in a loop until there are no fills left to allocate. You can use this as a standalone algorithm, or as a secondary algorithm to allocate leftover fills while using the pro rata algorithm.
You must define a hierarchy from the following options to determine which order receives the first fill, the second fill and so on around the loop:
First in, first out (FIFO)
With this hierarchy, fills are allocated one at a time to orders in the sequence they were created. For example, if there are two shares in an execution and three orders with outstanding fills, the first order is allocated one share, and the second order is allocated one share.
Last in, first out (LIFO)
Similar to the FIFO hierarchy above, but with fills allocated according to the orders created most recently. For example, if there are two shares in an execution for three orders, order three is allocated one share, and order two is allocated one share.
Largest order first
With this hierarchy, fills are allocated one at a time starting with the orders requesting the most fills. For example, if there are two shares in an execution and three orders with outstanding fills, the order with the most shares yet to be filled is allocated one share, and the order with the second most shares is allocated one share.
Smallest order first
Similar to the largest order hierarchy above, but with fills allocated according to the orders requesting the fewest fills. If there are two shares in an execution for three orders, the order with the least shares yet to be filled is allocated one share, and the order with the second least shares is allocated one share.
With the round robin algorithm, note:
- Fractional fills can be allocated to orders if only a fractional number of fills need allocating or to prevent over-allocation to an order.
- Orders can be allocated more fills than the quantity ordered. Fills are over-allocated once all orders in the block are 100% filled.
The following table shows how an execution containing 40 AAPL US equity shares might be distributed across a block of three orders using each algorithm:
| Order | Shares in order | Shares received in execution | Shares allocated according to selected algorithm | ||||
| Pro rata (with FIFO if required) | First in, first out | Last in, first out | Largest order first | Smallest order first | |||
| A | 30 | 40 | 12 | 14 | 13 | 13 | 13 |
| B | 15 | 6 | 13 | 13 | 13 | 14 | |
| C | 55 | 22 | 13 | 14 | 14 | 13 | |
Importantly, allocations are redistributed every time a new execution containing more fills is received, up until the point they are booked to portfolios as transactions. For example, if you receive a second execution of 10 AAPL US equity shares for the table of orders above, all 50 shares received in executions are reallocated according to the selected algorithm:
| Order | Shares in order | Shares received in first execution | Shares received in second execution | Shares allocated according to selected algorithm | ||||
| Pro rata (with FIFO if required) | First in, first out | Last in, first out | Largest order first | Smallest order first | ||||
| A | 30 | 40 | 10 | 16 (including +1 leftover share) | 18 | 17 | 17 | 18 |
| B | 15 | 7 | 15 (100% filled) | 15 (100% filled) | 15 (100% filled) | 15 (100% filled) | ||
| C | 55 | 27 | 17 | 18 | 18 | 17 | ||
Booking transactions
An allocation can be reallocated up until it is booked as a transaction. You can manually update allocations to redistribute fills until this point. You have several options for defining when an allocation should be booked as a transaction:
- Automatically at close of business or another specified time trigger.
- Based on the state, such as when a placement is 100% filled.
- On receipt of a Done for Day (DFD) FIX message for individual orders. For example, if a placement is configured to be filled over multiple days, upon receiving a DFD message and knowing you won't receive any more fills for the order that day, LUSID can book all existing allocations for the order as transactions.
- As soon as a fill is allocated.
Appendix A: Selecting allocation algorithm combinations
The following table lists all the valid allocation algorithm combinations and their corresponding code values:
| Algorithm | Code value | ||
| Base algorithm | Hierarchy | Second hierarchy (in the event of a tie in the first hierarchy) | |
| Pro rata | First in, first out | PR-FIFO (default) | |
| Largest first | PR-FIFO-LF | ||
| Smallest first | PR-FIFO-SF | ||
| Last in, first out | PR-LIFO | ||
| Largest first | PR-LIFO-LF | ||
| Smallest first | PR-LIFO-SF | ||
| Largest first | PR-LF | ||
| First in, first out | PR-LF-FIFO | ||
| Last in, first out | PR-LF-LIFO | ||
| Smallest first | PR-SF | ||
| First in, first out | PR-SF-FIFO | ||
| Last in, first out | PR-SF-LIFO | ||
| Round robin | First in, first out | RR-FIFO | |
| Largest first | RR-FIFO-LF | ||
| Smallest first | RR-FIFO-SF | ||
| Last in, first out | RR-LIFO | ||
| Largest first | RR-LIFO-LF | ||
| Smallest first | RR-LIFO-SF | ||
| Largest first | RR-LF | ||
| First in, first out | RR-LF-FIFO | ||
| Last in, first out | RR-LF-LIFO | ||
| Smallest first | RR-SF | ||
| First in, first out | RR-SF-FIFO | ||
| Last in, first out | RR-SF-LIFO | ||