Working with Monitoring Alerts

This guide covers the day-to-day workflow in the Monitoring view: reading alerts, filtering the queue, deciding what to act on, and resolving. It’s written for case workers — no technical background needed. For configuration, see Monitoring Alerts Settings; for the system behind the alerts, see The Monitoring System.

What an alert is

An alert means something changed on an entity you monitor: a screening hit (PEP or sanctions), a relation (roles, owners, ownership, beneficial owners), or company information (registry data, financials, lifecycle status, court cases). The alert shows what the value was before and what it is now — the judgement of whether the change matters for your customer relationship is yours.

Alerts arrive after each monitoring run — see screening cadence for when runs happen.

Reading the queue

The Monitoring view shows your team’s alerts in three tabs:

Unresolved — alerts nobody has handled yet. This is your work queue.
Recently resolved — what your team has closed lately.
Archived — the historical record.

Companies and Private persons have separate tabs, because they’re screened on different cadences and often handled by different processes.

Filters

Narrow the queue by:

Alert type — PEP, Sanctions, Relations, Company Information
Change kind — added, removed, or updated
Time period
Assignee — including Unassigned, which is worth checking regularly so nothing sits ownerless
Entity — all alerts for one company or person

Working an alert

Expand the alert to see the before → after change and the details behind it.
For PEP and sanctions alerts, you can verify the hit directly in the alert: confirm it as a true match or dismiss it as a false positive (dispositioning). The decision is recorded with your name and timestamp.
Assign the entity to a team member if someone specific should own the follow-up. Assignment is per entity — the assignee owns everything about that customer, not just one alert.
Comment on the alert if you want to leave context for colleagues or for the audit trail.
Resolve when handled.

What “resolve” means

Resolving an alert marks it as handled and moves it out of the Unresolved queue — with your name and the time recorded. It does not change anything about the entity itself: no status change, no review, no re-screening. If the change warrants deeper work, send the entity to Review before resolving the alert.

Resolve all closes every alert matching your current filters in one action — useful after a settings change floods the queue with alerts you’ve consciously decided not to act on. Each alert still gets an individual audit record, and resolved alerts can be un-resolved if you change your mind.

Where alerts come from — and why volumes sometimes jump

Two things generate alerts beyond real-world changes:

Settings changes. Tightening or loosening your screening settings changes what counts as a hit — the next run alerts on the difference. These alerts are marked as stemming from a settings change, so you can tell them apart from genuine new information.
Enabling new alert categories. Turning on a category (for example Company Information) makes the next run establish a baseline, which can produce an initial wave on a large portfolio.

Both are expected one-time effects, and Resolve all with a filter is the intended way to clear them once reviewed.

Email digests

If your team has email notifications enabled, unresolved alerts are also delivered as a daily digest email — one consolidated email per user, covering the last seven days’ unhandled alerts. Configure per-category recipients (everyone, only the entity’s assignee, or a shared team mailbox) in Monitoring Alerts Settings.

Good habits

Check Unassigned regularly. Alerts without an owner are where things fall through.
Filter by alert type when triaging. Sanctions and PEP alerts usually deserve attention before cosmetic company-information changes.
Resolve with intent. The audit trail of who resolved what, and when, is your evidence of a working monitoring process — supervisors sample exactly this.
Don’t fear Resolve all — but filter first. It’s built for settings-induced waves, not for emptying a queue you haven’t read.