Definition
Risk alerting is the practice of running automated checks against a live portfolio and surfacing notifications whenever a defined risk metric crosses a pre-set threshold. The thresholds may be on exposures, on drawdowns, on volatility, on margin utilisation, on concentration, or on operational signals such as feed staleness and order-router latency. The goal is to compress the time between the moment a problem becomes visible in the data and the moment a human or an automated control begins to act on it.
A complete alerting system has three layers. Detection rules compute the relevant metric on the freshest available data and compare it to the threshold. Routing decides who receives the alert — desk, risk officer, on-call engineer — and through which channel: pager, chat, email, dashboard. Acknowledgement and escalation make sure the alert is seen, owned, and either resolved or escalated within a defined window so nothing falls through.
Why it matters
How it works
Detection runs continuously against the same position and price data that drives the rest of the trading stack. Each rule consumes a stream of inputs, computes a metric, and emits an alert event when a threshold is crossed. Hysteresis — only firing once when the metric crosses up, and only clearing once it has dropped meaningfully back below — prevents flapping around the threshold. Routing then takes alert events and dispatches them based on severity, time of day, and on-call rotations.
The hardest part is not building the detector but tuning it. Set thresholds too tight and alarm fatigue sets in within a week; set them too loose and the system is silent through the exact event it was built to catch. Production-grade systems iterate the thresholds against historical data, classify every fired alert as actionable or noise, and prune or tighten rules until the actionable rate is high enough to keep humans paying attention. Alerting, like any production observability system, is a continuous discipline rather than a one-time configuration.