Advanced Aggregation and Scheduling

.
The standard flow in OACT is designed to efficiently and accurately process basic order flows. A number of Edge Cases are identified but not provided as configurations: instead, certain reprogramming would be necessary. OACT has been coded with the potential for reprogramming in mind, but such reprogramming would still require IT and other skills, as well as clear requirements. Refer to technical documentation, including the section dedicated to technical users.

Some of the edge-cases identified with regard to Advanced Aggregation and Scheduling strategies are listed here.

Institutional Share handling

In a scenario where a particular item has a minimum trade amount of 100, operators of OACT must want until the sum of an aggregation exceeds 100 before sending it to the channel. Therefore a Daily schedule for transmitting Aggregations would need to be disabled, and instead adjusted to send based on the order value.
Since Orders are Aggregated in real-time, the Aggregation must be monitored, and when the value surpasses 100 the Export can be triggered. This could be managed manually, or by reprogramming some triggers or procedures. Potential candidates for reprogramming, depending on Use-Case specifics, could be

  • Triggers on "aggregation update" - every time the Aggregation is updated, check if the value exceeds 100. If so, Route it immediately by calling the Aggregation Routing process
  • Export routine - wrap the existing export routing inside an additional IF clause: if the value exceeds 100, continue, else wait for the next Export.
  • Use oact_general_storage for storing any variables or settings needed for customized workflows.

Capped aggregated orders

There may exist cases where the Market allows only trading of a fixed maximum number of shares. If 100 shares are tradeable, a number of options are open for consideration.

  • Cap OACT orders at 100, so that if orders exist for 99, and a new order comes for 2, then that last order is reduced to 1 either automatically (with relevant information to the operator), or Reject the order and wait for an order of exactly 1. This requires customization, most likely in the order system or front-end (for example the OACT-GUI)..
  • Allow orders in excess of 100 units, and let standard OACT functionality distribute proportionally. In the example above, each order will receive [100/101}*[order Value}. No reprogramming is needed for this processing - refer to Distribution to Transactions for further information on proportional distribution. However, be aware of the risk that the final order might be for 1000 units, which would greatly skew the distribution in favour of the final order.
  • Allow underlying orders to exceed 100, but when the Confirmation arrives, distribute the confirmation amount (=100) on a first come, first served basis (or other order criteria). This would require reprogramming of the "confirmations insert" trigger (SQL). The last order would in this case receive only 1 share.
  • Use oact_general_storage for storing any variables or settings needed for customized workflows.

Granular Export Parameters

Currently OACT Routing Processes are run or scheduled based on Channel and a user-defined SQL filter. Some cases may exist where other factors need to be considered, such as some kind of approval routine, or dependency on data outside of OACT. Generally, additional complexity will require reprogramming, and potentially some adjustments to data-handling (in particular, the field order.order_grouping has been included specifically to facilitate such use-cases). As usual, code to be reprogrammed exists in the triggers for O,A,C, or T entities, as well as in the Routing Processes. It is possible that a lot of Logic needs to be inserted as new code, and developers should be mindful of the performance impact.