Reading is a great way to learn. However, it’s the practice of that knowledge which is a key part of the process. For example, you can read a lot about an area in mathematics, but it’s only once you’ve sat there for hours struggling to solve some problems that you begin to understand it. It’s the same with coding. Yes, reading through textbooks and attending lectures are a crucial part of the process. Again though, it’s the “doing”, sitting there, struggling to get code to compile and give you the expected output, that will cement certain concepts in your mind. Sometimes it can be useful to take a look back at a project to try to understand what precisely you’ve learnt from it and also what skills you could still improve upon. Hence, I thought I’d put that idea to the test with my latest project!
Over the past few months, I’ve been building a Python library for doing TCA (transaction cost analysis) for FX. I’m also hoping to open source some of the project, if I can get sponsorship from a financial firm or data company – indeed, if you’re interested in sponsoring the idea let me know, and read a bit of background about the project here. I thought it would a good to outline a few things which I’ve learnt from it! Some of what I’ve learnt has been about markets, TCA and also more broadly about coding and projects.
Execution is different from being a portfolio manager!
I’ve been doing FX my whole career. That kind of made me think I knew a lot about the market…. the project made me realise, that there’s an awful lot, I still have to learn about the market! In particular, my perspective has mostly been at the level of designing trading strategies, at intraday or daily time horizon, rather than thinking about the costs of execution. It was only later in my career, that I began to appreciate how important execution is to the success of a trading strategy. In part, I think it was because I had begun to work much closer with traders, and had taken an active role in trying to understand the divergence between actual execution of model versus traders fill of that model (which I didn’t do at all for the first few years).
For execution traders, clearly transaction costs are a key concern and also thinking about ways to minimise them. There needs to be a good feedback loop between execution traders and portfolio managers. If there is a lack of communication between the two parties, it can result in running strategies which can be killed by transaction costs. It can also be something that afflicts quants who develop trading strategies, but are far away from the market (I hate to admit this though!) – effective TCA can help with this feedback loop!
Software design will change throughout the project
Ok, this is blindingly obvious, but the software design of a library you think of before a project can change once you get down to coding it. Often, it can be the case that the specification of your library can change throughout a project, which necessitates this. It’s also the case, that over time, do you notice areas where substantial refactoring will make the code cleaner and easier to understand (and no, CTRL-C + CTRL-V is not software reuse!). Indeed, throughout this project, I have got more ideas on ways to simplify the code, which I didn’t think of at the outset.
There isn’t a one size fits all for TCA
One of the reasons I’m looking to open source the TCA library, is that how TCA is viewed differs between traders. If you are doing many thousands of trades a day, you probably don’t case about visualisation of individual trades. This contrasts to a trader making a much smaller number of trades a day, where this exercise can be a lot more valuable. Which metrics are important for you can also differ. Creating a library, which is open source and fully customisable, doesn’t force people into a specific way of doing their TCA. Instead it gives them the freedom, to modify the code till it exactly fits their trading style. In particular, making the code sufficiently generic is key to allow people to modify it.
Know where to spend time when optimising code
It’s easy to get sidetracked and optimise bits of code, because it looks more “elegant”. I ended up using a code profiler to try to identify code bottlenecks. Invariably, the slow bits of code, were not where I expected them to be. Sometimes, it was due to excessive usage of for loops, which are pretty slow in Python, if they are executed over many iterations. You of course need to be careful when optimising the code. Yes, doing lower level coding can improve the performance, but we need to strike a balance between that and making sure the code is readable. By making the code quick, it makes the TCA process interactive, so that traders can run analysis, see the output and then re-run etc. TCA is no longer simply a PDF document which gets generated overnight, and gets sent to a trader.
There’s always a lot left to learn
About TCA, coding and markets more broadly…!