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.