Bugs in trading software can be a very nasty thing. Think about Knight capital in 2012 where a single coding bug resulted in a 440 million dollar loss within a single day, several times greater than the company’s yearly profit. In this case the problem was simply that orders that needed to be executed over a given period of time where executed within a single day, a huge oversight from one or potentially several programmers working at the company. On today’s post I am going to talk a bit about my experience with bugs in algorithmic trading and what constitutes a potentially good plan to both prevent their appearance and deal with them once they have been discovered. We’ll discuss where bugs can happen, what types of bugs can happen and how to deal with these different problems.
–
–
Algorithmic trading efforts are usually complex and involve several different programs. Traders commonly use a piece of software to perform simulations and another piece of software to carry out live trading. In the best of cases simulations are executed using the same code on both programs – usually through the use of libraries – but sometimes there are different pieces of code for simulations and live trading (what many people who do simulations in R or Excel and live trading do). Bugs can generally show as either problems with what is coded – the code is not doing what the programmer wants it to do – or as problems with what the programmer thinks must be done (the code is doing what it’s supposed to do but the programmer has a wrong idea of what has to be done). In the first case we have an error in coding and in the second we have an error in logic.
Errors in coding can generally be prevented by the use of good software programming practices, such as unit testing. The idea in this case is to have a set of example function calls which are executed within a program to generate a known output. For example if you have a function that returns the profit per trade as a function of the open price, close price, trading volume and the trade type and you know that the return should be X for a trade opened at A and closed at B with C lots then a call to test that function with those inputs would constitute an initial test that the function is working correctly. Calls to test this function should include different cases, such as longs, shorts, different symbols, etc. Once the function is coded the unit test provides a correct assessment of whether the function is doing what the programmer thinks it should be doing. If the code is modified a unit test quickly lets you know if something you did broke something or if everything is working exactly as before.
–
–
Although the above can help you eliminate cases where you either introduce coding errors or have coding errors to start with there is nothing in unit testing that will prevent errors in logic as these come from misunderstandings by the programmer of what has to be done. If your code is doing what you want it to do but what you want it to do is wrong then you have a logic error within your programming that you simply cannot detect until you realize that what you have coded is indeed logically wrong. The best way to confront this is to have several different people use the code in which case glaring errors in logic are bound to show as different users put their own logic against what they believe the program is supposed to do. This is one of the great strengths of community projects where a community can help you catch errors in logic that would otherwise go unnoticed if you were the only one to use your programs.
When dealing with live trading software another feature that you must put into place is to consider scenarios that should never happen and put in place barriers to stop them regardless of what their source might have been. Maybe there is some error you have not noticed that under some rare circumstance might cause the calculated lot size for your trades to be 100x what it’s supposed to be, in this case you should put into your software a safeguard that stops everything or prevents execution if the lot size is above the maximum lot size you would consider would be traded within your logic. In the case of Knight capital they might have saved a good chunk of the money they lost if they had had such a worst case restriction in place (for example dealing with the maximum number of orders that could be executed within a given timeframe). These worst case restrictions are not something that should be hit often but they are a safeguard against potentially capital-wiping events that might happen because some unforeseen circumstance might have happened. In the same spirit you might also consider limiting your account leverage to the maximum you intend to use such that if you have some error that places a huge trade it cannot go through by a broker-side restriction. It’s of no use to have a 1:100 leverage available if all you will use is 1:10. If all you’ll use is 1:10 then go maximum 1:15.
–
–
Given the above it is not surprising that however hard you try there might always be some error that you did not account for, especially logic errors, that heavily affect either your live trading or your back-testing results. Whenever you find a logic error it might not be easy – it might involve restarting or rethinking a large part of what you’re doing – but in any case make sure you fix and confront the error as soon as possible. With logic errors the best thing you can do is implement the fix and bite the bullet as quickly as you can, making sure that you re-evaluate your trading operation after fixing the error to change anything that has to be changed due to this fact. This happened to us last week at Asirikuy where a logic error within a piece of code used in back-testing caused us to re-evaluate our machine learning trading strategy portfolio. We had to restart our cloud based machine learning portfolio mining effort but we were able to significantly increase the reliability of these simulations by performing these modifications.
All-in-all it’s always important to have a plan for bugs within your trading software. It’s not a matter of “if” there will be a coding or logic error within your software but it’s really a matter of when these errors will happen and how bad these errors will affect your business. In any case implement everything you can to ensure that coding errors are unlikely – unit testing, functional testing, etc – and also implement breaker switches dealing with worst cases so that unforeseen errors do not result in circumstances that imply large monetary losses. You will most likely always find errors that will have an impact within your trading but you can do your best to minimize the damage they cause and do your best to implement fixes and assess damages as quickly as possible. If you would like to learn more about our trading and our community please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading.
