Most risk rules are written to be agreed with, not checked. "Keep drawdowns under control" and "avoid oversized positions" are hard to dispute and impossible to audit. When a review asks whether a strategy respected its limits, rules like these produce a discussion instead of an answer.
This article covers how to word risk rules so a breach is a fact rather than an opinion, with examples of weak and strong wording, a worked check on a simulated run, and what an audit trail entry should contain when a rule or its outcome changes.
Why most risk rules cannot be audited
An audit asks a narrow question: given the record, was the rule followed? To answer it, three things must be true. The rule must refer to a quantity that is actually recorded. It must say when that quantity is measured. And it must say what happens when the threshold is crossed.
Regulated firms face a version of this requirement. The SEC's market access rule requires broker-dealers to have controls that reject orders exceeding pre-set credit or capital thresholds and orders that exceed appropriate price or size parameters, and to review those controls at least annually under written, documented procedures (eCFR, 17 CFR 240.15c3-5 (external site)). FINRA's guidance on algorithmic strategies lists documenting and periodically reviewing parameter settings for risk controls among effective practices (FINRA Regulatory Notice 15-09 (external site)). The word that matters in both is pre-set: the threshold exists, as a number, before the activity it constrains.
A research team reviewing simulated strategies is not subject to those rules. The discipline still transfers well.
Four properties of an auditable rule
1. Measurable. The rule names a quantity that can be computed from the record: equity, position value, trade count. "Excessive risk" is not a quantity. "Position value as a percentage of equity" is.
2. Defined reference point. Percentages need a denominator. Drawdown from which peak? Daily loss relative to which equity figure: start of day, previous close, or initial capital? Different answers produce different breach dates.
3. Defined evaluation time. When is the rule checked? At each bar close, at each order, at end of day? On daily bars with fills at the close, an intraday loss limit cannot be evaluated honestly, so the rule should say "at the daily close" rather than imply continuous monitoring.
4. Defined consequence. What happens on breach: block new entries, close all positions, halt for the rest of the day, halt for the rest of the run? A rule with no consequence is a metric, which is fine, but it should be labelled as one.
Bad versus good rule wording
| Weak wording | Problem | Auditable wording |
|---|---|---|
| "Don't let any position get too big." | No quantity, no threshold | "Position value ≤ 20% of equity, measured at each fill. Orders that would exceed it are reduced to the limit." |
| "Stop trading if drawdown gets bad." | No reference peak, no threshold, vague action | "If equity at the daily close is ≥ 15% below its highest prior daily close, close all positions and halt for the rest of the run." |
| "Limit daily losses to about 2%." | "About", no denominator, no action | "If equity at the daily close is ≥ 2.0% below equity at the previous daily close, no new entries on the next trading day." |
| "Avoid overtrading." | No count, no window | "Max 6 fills per trading day. The 7th order of the day is rejected." |
| "Risk limits reviewed regularly." | No interval, no owner, no record | "Rule thresholds reviewed at each report revision; every change logged with old value, new value, author and reason." |
The right-hand column is longer and less elegant. That is the price of being checkable.
A worked example: checking a daily loss rule on a simulated run
The numbers below are illustrative, from a hypothetical simulated run on synthetic data, not market data.
Rule R3, as written: "If equity at the daily close is ≥ 2.0% below equity at the previous daily close, no new entries on the next trading day."
| Day | Close equity | Change vs previous close | R3 status | Action |
|---|---|---|---|---|
| 36 | 104,800 | +0.4% | Pass | — |
| 37 | 102,170 | −2.51% | Breach | Entries blocked on day 38 |
| 38 | 101,900 | −0.26% | Pass (blocked day) | Two exit fills, no entries |
| 39 | 102,600 | +0.69% | Pass | Entries resume |
The check is mechanical: (102,170 − 104,800) / 104,800 = −2.51%, which crosses −2.0%. The verdict does not depend on who reads it.
Now consider the weak version, "limit daily losses to about 2%." Was day 37 a breach? Is 2.51% "about 2%"? Should it be measured from the day's peak, which on daily bars is unknown? The same run produces an argument instead of a log line.
One more detail matters: under the strong wording, day 38's two fills were exits, which the rule does not block. If the run had instead opened a new position on day 38, the audit would show a rule that was evaluated correctly but not enforced, a different and more serious finding.
What an audit trail entry should contain
An audit trail records events: a rule was created, a threshold changed, a run breached a limit, a report was exported. NIST's control catalogue offers a sensible baseline for the content of each record: what type of event occurred, when, where, its source, its outcome, and the identity of the individuals or entities associated with it (NIST SP 800-53 Rev. 5, AU-3 (external site)). The same document calls for time stamps in Coordinated Universal Time or with an explicit UTC offset (AU-8).
Translated to strategy review, a useful entry holds:
- Event type.
rule_changed,rule_breached,parameter_changed,report_saved,exported. - Timestamp in UTC. When the event was recorded, not when someone remembers it happening.
- Actor. The user or process that caused it.
- Object. Which rule, parameter or report, by stable identifier (R3, not "the daily loss one").
- Before and after values. For a change, both. A new value alone hides what was relaxed.
- Report version. The revision the event belongs to.
- Reason. A short free-text note. Optional in a tool, mandatory in practice.
- Outcome. For a breach: the measured value, the threshold, and the simulated date it occurred.
An example entry for the run above:
2026-10-18T14:02:31Z rule_breached actor=simulation report=rev-4
rule=R3 max_daily_loss threshold=-2.00% measured=-2.51% sim_day=37
action=entries_blocked sim_day=38And a change made afterwards:
2026-10-18T14:09:05Z rule_changed actor=analyst-2 report=rev-4→rev-5
rule=R3 max_daily_loss before=-2.00% after=-3.00%
reason="Align with team policy for this template"The second entry is the one reviewers should look for. Loosening a threshold after seeing a breach is not always wrong, but it should never be silent.
Changing rules without rewriting history
FINRA's guidance recommends a change management process that tracks material changes to code, includes review and approval, and archives versions in a retrievable manner (FINRA Regulatory Notice 15-09 (external site)). The research equivalent is simple:
- Never edit a saved report in place. Save a new revision.
- Keep breaches attached to the rule version that produced them. A breach under R3 at −2.0% stays a breach even after R3 is changed to −3.0%.
- Rerun after a change, and keep both runs. The comparison is the evidence.
- Review the change log before the results. If thresholds moved repeatedly toward the outcome, that is a finding in itself.
Where Monoqant fits
Risk Rules supports four checks on a simulated run: max position %, max drawdown stop, max daily loss and max trades per day, each evaluated on synthetic daily bars with fills at the close. The audit trail records creation, parameter changes, rule changes and exports against versioned report revisions. Monoqant does not connect to brokers or execute trades, so these are checks on a simulation, not live controls. For the broader review order, see how to review an AI trading bot; the methodology page documents how each rule is computed.