The kill switch is a requirement for a modern automated trading environment. The term is pretty generic and can include capabilities such as:
This sort of control mechanism is one that is seldom considered as glamorous, since it only comes in to use to mitigate a failure. But money spent on a kill switch is viewed in a very different light either after then first failure that could not be mitigated since there was no kill switch or after a failure is mitigated by an implemented kill switch.
In other words, a kill switch is like a car airbag. Not something you think about, until you need it. And when you need it, you really need it and need it to work properly
- Cancel all orders at a specific venue
- Cancel all quotes at a specific venue
- Cancel all orders at all venues
- Cancel all quotes at all venues
- Cancel all orders at a specific venue for a specific client
- Cancel all orders at all venues for a specific client
- Cancel all orders at a specific venue for a specific trading book
- Cancel all orders at all venues for a specific trading book
- Cancel all orders for a specific trading algorithm
A substantial part of the requirement is for certainty of functionality, that the user who activates the kill switch has a high degree of certainty that the kill switch will operate "as advertised" and perform the function properly. No one wants to hit a kill switch and find out later that a misbehaving algorithm has burnt up millions of £$¥€...
Within a sell-side firm with connections to multiple markets the implementation of a kill switch can become challenging. Each execution venue may use different protocols (FIX 4.2, FIX 4.4, FIX 5.0 SP2, ITCH/OUCH, proprietary) and each venue may or may not have the ability to mass cancel orders or quotes.
One very cute implementation of this is a combination of packet capture, switches and FPGA. In essence, the IP connections to execution venues are routed through a packet capture implementation which then decodes the TCP/IP, evaluates the current state of the orders/quotes that have been sent and persists this state. If and when a user executes the kill switch the FPGA in the switch at the edge of the network then sends the messages to the execution venues to kill quotes and/or orders.
This requires a high degree of knowledge of the peculiarities of the market - will it accept mass quote cancels and other ways to get out of the market quickly. Or would it be quicker to simply execute a "cancel on disconnect" functionality and drop the TCP/IP session?
This requires a high degree of knowledge of the peculiarities of the market - will it accept mass quote cancels and other ways to get out of the market quickly. Or would it be quicker to simply execute a "cancel on disconnect" functionality and drop the TCP/IP session?
This sort of control mechanism is one that is seldom considered as glamorous, since it only comes in to use to mitigate a failure. But money spent on a kill switch is viewed in a very different light either after then first failure that could not be mitigated since there was no kill switch or after a failure is mitigated by an implemented kill switch.
In other words, a kill switch is like a car airbag. Not something you think about, until you need it. And when you need it, you really need it and need it to work properly
It is rather sad that FIX did not add kill switch into its protocol. Your list above should just be a valid values list for such a message.
ReplyDelete