There are many online sources about common risk factors in investing and trading e.g. market risk, credit risk, interest rate risk. There are various factor models (Fama-French, Carhart) and risk management methods to mitigate them.

What are examples of non-financial risk, such as hardware or network connection failure, death/injury of an employee, that quant trading firms face? Are there any decent examples of risk mitigation or contingency planning methods for such risks that are available online?

  • $\begingroup$ This is a very broad question, including anything under the sun; can you tighten up your definition of non-financial risk a little? $\endgroup$
    – Shane
    Feb 15, 2011 at 19:13
  • $\begingroup$ This seems more business logistics than quantitative finance. How to value / price Key Person Insurance would be more on-topic. $\endgroup$ Feb 15, 2011 at 19:16
  • $\begingroup$ @Shane Tried to focus it more... $\endgroup$ Feb 15, 2011 at 19:34
  • $\begingroup$ @Joshua I don't see how you tightened it up at all. You're still asking about any and every non-financial risk. $\endgroup$
    – Shane
    Feb 15, 2011 at 19:45
  • $\begingroup$ I'm not sure asking about non-financial items on a quant finance site is in scope. You might want to check with Server Fault for this kind of stuff. $\endgroup$ Feb 15, 2011 at 19:57

4 Answers 4


To give an example of a source of risk that isn't one of the ones you mentioned but still broadly on-topic for a Quant Finance site: operational risk - for which there are many references for contigency plans. This is the domain of the back office. Trades are created (priced and analysed) by quants, executed by traders and approved by preferably at least one other person (called "four eyes approval") before being officially agreed.

This is concerned with Trade Administration. A trade goes through several states with different permissions required to move a trade from one state to the next e.g. pending, approved, rejected, confirmed, cancelled, expired, with only certain transitions being allowed.

Back office software can ensure that different sets of employees within a bank or other financial instution can only perform certain tasks and enforce limits on trading positions etc. The cost of the added complexity to the system is designed to minimise operational risk and generally prevent "rogue trader" scenarios.


There are all sorts of financial and non-financial risks.

I define financial risk as all risks defined from events in the financial markets that affect all participants. Non-financial risks are all other forms of risk (including risks that a particular firm may face).


  • Market value risk (interest rate risk, exchange prices, equity prices, commodity prices, etc.)

  • Credit risk (downgrade, default, credit spread risk)

  • Liquidity risk


  • Model Risk
  • Operational Risk (fraud, misconduct, failure of internal controls or audit systems, natural disasters)
  • Settlement risk
  • Accounting risk (changes in GAAP/IFRS and comparability issues, managed earnings, etc.)
  • Regulatory risk
  • Legal risk (counterparty does not honor a contract)
  • Tax risk
  • Sovereign risk (if you are trading EM debt for example) & Political risk
  • Performance netting risk
  • Key Man risk
  • $\begingroup$ I am curious: why do you classify Sovereign and Settlement Risk as Non-Financial? $\endgroup$
    – Ryogi
    May 12, 2012 at 8:04
  • 2
    $\begingroup$ @Ryogi - I updated my answer to clarify the distinction I had in mind. With some imagination all non-financial risks could be construed as financial risks because you could assign a monetary value to each of these. So I attempt to draw a bright line. $\endgroup$ May 14, 2012 at 15:22

I consider market risk, credit risk and operational risk to be the three major forms of financial risk exposure. @jeebs addressed the trade settlement component of operational risk. I would also include the third bullet point that @shane gave in his answer as belonging to the category of operational risk.

Another form of non-financial risk would be political risk, if one is trading in securities that are sourced from a single country e.g. commodities, or traded on a foreign exchange which may become unstable due to political turbulence. Contingency plans would be to trade the same commodity, but perhaps the futures or options on that commodity, or trade the same commodity if listed on other exchanges.

Political risk can also be mitigated by investing in similar but not quite as high yielding securities. For example, if one wanted to invest in developing nations sovereign debt in the past, but have the transaction denominated in a major currency, there were Brady Bonds, which were $US denominated. The same is still true if one is willing to relinquish some return, by buying large corporation bonds from say, Mexico, but denominated in Canadian or US dollars, rather than Peso's.

Finally, there is liquidity risk. If a market is not deep enough, with enough daily (or weekly) transactions, one can get stuck in a position. This can happen in any market, any security type, any where.


Data is the lifeblood of a quantitative strategy. So I would say that the primary operational risks facing quantitative models are related to data.

Some places where this can be an issue:

  • Misinterpreting post-hoc data: Many economic indicators are revised on a periodic basis, and it's critical to understand what the meaning of the numbers are on a real-time basis. Similarly, some exchanges will provide price corrections, and you need to determine whether these would have been applied to your data. Lastly, some historical price data is indicative (i.e. not real tick data) because it has been scrubbed or averaged in some way.
  • Data outliers and changes: Data inevitably has problems due to any number of factors, ranging from outliers or errors to re-scalings (and corporate actions).
  • Unexpected infrastructure failures: No computer system is perfect. It's critical to understand the likelihood of a down-time, whether related to a data feed or some other aspect of your infrastructure, and either build these assumptions into your model or else mitigate these risks through redundancy and failover.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.