Monitoring rule review: what the decision maker looks at
A monitoring rule review checks whether an alert reflects a genuine risk signal or a false positive produced by the rule's own parameters. The reviewer looks at the transaction pattern, the customer's risk profile, prior alerts on the same account, and whether the rule's threshold still matches the current typology. The outcome decides whether the alert is closed, escalated, or used to retune the rule.
What changes once a review opens
Opening a review starts a clock inside the compliance function, not a statutory clock. From that point, the case sits with a named reviewer, and the file must show who looked at it and when. A review that stalls without a documented reason becomes a finding in its own right, separate from whatever the original alert was about.
Unresolved reviews accumulate exposure. If several alerts on the same customer stay open past the firm's own escalation point, the file typically moves to a senior compliance officer, and in serious cases to the board-level committee. A parallel situation with a similar escalation logic is described in A licence is suspended pending review authorisation the deadline, where a pending review has its own separate consequence for the firm's authorisation.
What to do
- The alert owner pulls the underlying transaction data and the customer's existing risk file before touching the rule logic itself.
- The reviewer checks whether the same pattern triggered previous alerts and how those were closed.
- The reviewer records a written rationale for closing, escalating, or flagging the rule for retuning — a verbal decision is not sufficient.
- The rule owner tests any proposed threshold change against a sample of historical data before it goes live.
- The compliance officer signs off on any change that affects more than one customer segment.
- The file owner stores the decision, the underlying data extract, and the sign-off together, not in separate systems.
Who decides
| Stage | What is checked | Typical outcome |
|---|---|---|
| First-line triage | Whether the alert matches a known, already-assessed pattern | Closed with a short note, or passed to the reviewer |
| Reviewer assessment | Transaction detail, customer risk profile, alert history | Closed, escalated, or flagged for rule retuning |
| Rule-owner testing | Whether a proposed threshold change reduces noise without hiding real risk | Change approved, rejected, or sent back for a narrower fix |
| Compliance sign-off | Whether the change is proportionate and documented | Formal approval recorded in the file |
For a single alert, the reviewer decides. For a change to the rule itself, the decision moves to whoever owns the monitoring system, with the compliance officer holding the final sign-off. Neither role should be the person who raised the original alert.
Where this splits into different scenarios
If the alert concerns a customer with assets pledged as collateral, the review has to account for who currently controls those assets before any account restriction is applied. That question is separate from the monitoring rule itself and is covered in When a pledge over rights is enforced.
If the monitoring system itself was supplied by a third party and the alert traces back to a configuration error on the vendor's side, the firm's first move is contractual, not procedural. The relevant question — whether the vendor owes an indemnity for that error — is addressed in When a supplier refuses an indemnity.
If the delay sits with the monitoring platform's uptime rather than with the review itself, a separate service-level question arises about whether the vendor's own credit regime has been triggered. That mechanism is set out in When an SLA credit regime is triggered.
What this page does not decide
This page describes an internal review procedure, not a statutory obligation with a fixed deadline. It does not set out reporting thresholds, does not name the supervisory authority's own timeframes, and does not replace the firm's own written escalation policy. Where the review touches a licence condition, a pledged asset, a supplier contract, or a service-level agreement, the relevant page above governs that specific point.
Verified
State of description: this page reflects an internal escalation procedure as commonly structured across monitoring functions, not a cited statutory deadline. No external act or regulation is referenced on this page by design, since the underlying obligations sit at national level and are addressed on the pages linked above. Last reviewed: 4 October 2025.
Related publications
A comparable procedure, built around the same decision-maker structure, is set out in Supervisory questionnaire response step by step.
FAQ
How long does monitoring rule review take in practice?
Low-severity alerts are usually closed within the same working day. Cases that require escalation to a senior officer or a rule change typically run several working days, depending on how many flagged accounts and business lines are involved.
Which documents are needed to start?
The underlying transaction data for the flagged period, the customer's existing risk file, and a record of any prior alerts on the same account. Without these three, the reviewer cannot form a documented rationale.
What happens if the alert owner does not respond?
The review does not stop; it moves up. A non-response from the first-line owner is itself recorded as a gap, and the file passes to the reviewer or the compliance officer with that gap noted, not silently filled in.