High-frequency risk management methodologies

Question

In a high-frequency environment, such as a proprietary trading firm or market making firm, the primary goal of the risk management team would be to limit potential losses, but how is that done in this specific environment?

What kind of risk models are used in a high-frequency context? I have a basic understanding of (quantitative) risk management/models, but not in a setting where data is high-frequency and irregularly spaced. Does this change the modelling substantially?

Furthermore, are the following also major considerations?

• Review code written by traders to check for possible shortcomings.
• Review strategies and models to ensure they are sound.
• Check trade permissions, position limits.
• Check the data in use.
• Check the hardware and software in use.

If they do, could you expand on how so?

Thank you in advance.

Answer 1

I haven’t worked with HFT infra but for MFT something along these lines is necessary.

The infrastructure for deploying high frequency trading is very complicated and unique for most firms. There’s no any single solution fitting all cases. However, for simplicity you can categorize risk rules into three groups (made up names): infra risk, model specific risk, and system wide risks. Each of these is handled by relevant teams.

Infrastructure risk: basically, you need a dev team to ensure all the software/hardware is working as expected and have an action plan in case of failure. That includes necessary steps to ensure code quality (code review, testing, CI/CD), handling trading component connection/reconnection (pigs, FIX protocols, data feed connections), throughput control, latency consideration etc. As you can see, these incorporate some risks but they are “IT” intensive and usually a researcher or trader wouldn’t want to be responsible for them. A trader can monitor them and decide what to do if something goes wrong.

Model specific risks: specific to researchers, this really depends on what you have deployed and how possibly things could go wrong both from theoretical and implementation perspective.

System wide risks: compliance and the things you listed. Trading servers usually have an Execution Management System (EMS) which handles all the communications with the venues and double checks stuff before they go out. For example, if you have maxPositionSize per instrument you can implement a logic here which will reject anything above that and preferably notify trader. Since compliance rules can be complicated EMS are designed to handle the technical ones.