How Prop Firms Can Set Detection Sensitivity Around Their Risk Appetite

A Risk Director is reviewing two losing trade sequences. In the first, the trader increases position size once, then stops. In the second, the trader increases size after successive losses and continues the sequence. Both contain some form of loss-following exposure, yet the firm may only want the second pattern brought into review under its martingale policy.

That boundary is a business choice before it becomes a configuration choice. The team has to state what expression of the behaviour matters to its programme, what should stay below the line, and which facts could change the reading.

Configurable sensitivity helps represent that choice for each detection type. A useful setting is one the firm can explain through cases, rather than a label that sounds strict or permissive.

Set detection sensitivity by defining the policy boundary for one detection type, testing representative activity below, near, and above that boundary, and checking whether the resulting cases match the firm's intended review scope. Firms can configure sensitivity per detection type and toggle individual types on or off. Firm staff set policy and make every final decision.

Define the operating meaning before the setting

Start with a plain-language question: when does this behaviour become relevant to our firm?

The answer should describe observable activity. "We have a low appetite for martingale" does not yet tell a team where the line sits. A more useful policy statement might explain that repeated increases in position size after losses become relevant when they form a continuing sequence within a defined period.

Frequency, timing, position size, sequence length, or another observable characteristic may matter, depending on the detection type and the firm's policy. The aim is to identify the facts the firm considers meaningful without treating a general market norm as its own boundary.

This sequence keeps the reasoning clear:

1. State the behaviour the firm is concerned about.
2. Define what makes that behaviour material under its policy.
3. Identify the activity that sits just below and just above the intended line.
4. Configure and test sensitivity for that detection type.

If the team begins with the setting, policy can drift toward whatever the control happens to permit. Beginning with operating meaning gives the configuration something definite to represent.

Work through an illustrative threshold

Consider a hypothetical prop firm that wants a martingale detection to bring repeated loss-following size increases into review. For calibration, the firm creates the following illustrative policy choice:

Bring a sequence into review when a trader increases position size after two successive losing closes in the same instrument, then opens a third larger position within the period defined by our policy.

This is an example of a firm-side threshold for discussion. It is not a Stackorithm product default, a description of its interface, or a recommended martingale rule.

The team now has cases it can compare.

Below the proposed boundary: A trader has one losing close, increases the next position, then ends the sequence. Under the illustrative policy, that case stays below the chosen line.

At the boundary: A trader has two successive losing closes, increases size after each, and opens the third larger position within the defined period. The firm expects this activity to come into review.

Above the boundary: The loss-following increases continue across further trades in the same sequence. The firm expects the configured detection to continue identifying the pattern.

Context case: One of the trades was reduced before closing, or the apparent sequence spans activity the policy treats separately. The numerical condition may appear close, but staff need the surrounding facts to interpret it correctly.

This exercise gives the Risk Director a concrete basis for judging sensitivity. The question becomes whether the intended cases appear on the intended side of the line.

Calibrate for inclusion and exclusion

Every sensitivity choice affects what is included and what remains outside the configured condition. More sensitive analysis can bring weaker or earlier expressions of a pattern into view. A narrower configuration can focus the output on stronger expressions while leaving more borderline activity outside it.

Neither direction is inherently right. The practical test is whether the split matches the firm's stated appetite for that behaviour.

Review a small set of historical or constructed cases and ask:

• Does activity the firm considers clearly relevant meet the condition?
• Does activity the firm considers acceptable remain outside it?
• Are near-boundary cases represented often enough to test the policy choice?
• Can staff explain why the chosen split makes sense in operating terms?

If clearly acceptable cases repeatedly appear, check whether the setting or the policy definition needs refinement. If clear cases remain outside, examine the same two possibilities. Calibration should improve alignment, rather than chase a preferred number of findings.

Configure each detection type separately

A single sensitivity position across every behaviour would flatten meaningful differences. Detection types rely on different patterns and evidence, and a firm may have a different appetite for each one.

For every enabled detection, keep a short calibration record:

• the policy concern;
• the intended boundary;
• the cases used for testing;
• the reason the chosen sensitivity fits those cases; and
• the date and owner of the latest review.

A firm can also toggle specific detection types on or off. That choice should be deliberate. Record why the type is enabled or disabled and revisit the decision when the firm's terms or risk position changes.

Changes in programme design, account conditions, or observed activity may justify recalibration. One surprising case on its own is usually a reason to inspect the definition, not automatically move the line. Returning to the original test set helps the team see whether the context has changed or whether the case is simply unusual.

How Stackorithm can support this work

Stackorithm lets firms adjust sensitivity by detection type and turn specific types on or off. That gives a firm's policy a clear way to show up in configuration without handing decision authority to a setting.

The strongest configuration is tied to a clear policy choice and realistic examples. Select one detection type and place four cases on a page: clearly below the boundary, at the boundary, clearly above it, and context-dependent. Ask the policy owner to mark the expected treatment before discussing the current setting.

See how Stackorithm supports a broader trader-intelligence approach with sensitivity configured by detection type.

Book a demo