FIX Protocol Enables Pre-Trade Allocation
By Damian Bierman, Global Co-Chair, Asia Pacific Technical Committee, FIX Trading Community, and Head of Asia-Pacific, Portfolio Management & Trading Solutions, FactSet
Regulators should recognise the properties of the FIX protocol in their discussions about the merits of introducing pre-trade allocation rules.
There are already established standards and processes in place for buy-side firms to communicate share allocations to their brokers. Most fund managers should be able to send instructions in their native jurisdictions using the FIX protocol, which is well-equipped to channel and manage the information efficiently.
Moreover in several markets, such as Taiwan, there are regulations that stipulate that allocation information must be communicated on a pre-trade basis. Buy-side institutions need to show accurate allocation details when sending their orders across so that brokers can check if they have sufficient funding to make a purchase or enough shares to make a sale.
In some cases, institutions will have an omnibus agreement in place whereby their broker can use an agreed-upon allocation scheme to handle the requirement, and in such cases, typically an omnibus ID suffices, and individual account and allocation details need not be sent.
In other instances, where it’s determined that there is a need to send individual account allocations to the broker, the responsibility usually falls to the trader to communicate this information. If it’s not transmitted electronically at the time of trade, that is, directly from the trading system via FIX, then it has to be sent by some other means, and usually this means via email or chat. While this is understandably less complex from a systems integration standpoint, it means that the job is essentially a manual one, and therefore requires more time, focus, and effort on the part of the trader.
In today’s world of rising trade volumes and increasing complexity, there’s a good case to be made for streamlining manual processes when possible. Indeed, the Securities and Exchange Board of India is, it seems, discussing the merits of introducing regulations similar to those already in place in Taiwan, so it is apposite and timely to consider how FIX can help bring further efficiencies to workflows.
Pre-allocation information can be sent electronically via FIX today using the Tag 78/79/80 repeating group. By specifying the underlying account and share allocation information through these tags in the new order message, buy-side traders can be freed from having to communicate the information manually, and brokers can run their pre-funding checks in a more systematic fashion.
Nevertheless, as with most matters pertaining to electronic trading, it is wise not to oversimplify, because the devil is always in the details. There are a number of factors which can add complexity to the workflow, and it is the role of the industry’s trading technologists to work through the various scenarios to make sure that the nuances are being accounted for.
For instance, at a given firm there could be internal requirements that stipulate that pre- and post-allocation information match perfectly. In such cases, the trader needs to be able to control whether the account information is sent, and this can impact how the resulting child orders are traded.
Another complicating factor comes with handling order amendments. Additional quantity, potentially with new or different account information, can be added to the upstream parent order at any time throughout the day, and this will have to be taken into account when sending updated allocation information across in new child slices.
Despite these (and other) complexities, having the ability to transmit pre-allocation information natively via FIX is already creating efficiencies in the order-execution lifecycle. As new regulations are being considered by markets throughout the world, the practice of streamlining this workflow via FIX has the potential to gain additional traction in the near future.
We’d love to hear your feedback on this article. Please click here