Controls
The rule in someone’s head is not a rule
Every desk has policies that live in the experience of two or three people. They work until those people are on holiday, and they are impossible to review because nobody has written them down.
See it live
Policy expressed as a schedule, not a memory
Tiered conditions and the actions they trigger are laid out as a rule set the whole desk can read, rather than living in one person’s head.
Anatomy of a rule
Four parts, and the last one is where rule sets go wrong
Scope
Which clients, segments, instruments or platforms the rule applies to. A rule with no scope is a rule that will eventually catch somebody you did not mean to catch.
Condition
What has to be true for it to fire — exposure, loss, utilisation, behaviour, time of day, or a combination. Conditions are composable because real policy usually is.
Action
What happens: alert, flag, require approval, restrict, close. Most useful rules act rather than notify, since a notification simply moves the work to a person.
Exception
Who is excluded, why, and until when. Every exception carries an expiry, because the ones without a date are the ones nobody can later explain.
From draft to live
No rule reaches a client without a shadow period behind it
- 01
Draft
Written and scoped, affecting nothing yet.
- 02
Shadow
Evaluated against live activity, recording what it would have done.
- 03
Review
The shadow output is examined — how often it fired, and on whom.
- 04
Live
Enabled, with the shadow record as the evidence it behaves as intended.
FAQ
Rule automation: common questions
6 short answers to what teams ask before a demo.
Yes, and you should always do so. A rule runs in shadow first, evaluated against live activity and recording what it would have done without doing it. The shadow output is what tells you whether the threshold is sensible.
There is no imposed ceiling — unlimited in practice. The practical limit is comprehension: a rule set nobody on the desk can explain is a liability regardless of how well each individual rule is written.
The more restrictive action wins, and both firings are recorded. Conflicts are surfaced during the shadow period precisely so they are discovered before a client encounters the contradiction.
The interface requires an expiry. Permanent exceptions are the mechanism by which a carefully designed rule set quietly stops applying to the clients who most warranted it.
Whoever your policy allows, with the change attributable and versioned. You can see what a rule looked like on any past date, which matters when reviewing a decision made under an earlier version.
Yes. Conditions can reference behavioural profile — typical size, hold time, session pattern — so a rule can act on a departure from a client's own baseline rather than on a fixed threshold that fits nobody exactly.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistWhich of your rules are only in someone’s head?
Writing them down is usually the most valuable hour of a risk project, and it happens before any software is involved.