Alert Routing and Review Tiers
Every alert that isn't auto-approved (see How It Works?) is routed to exactly one of four review tiers — L1, L2, L3, or the Money Laundering Reporting Officer (MLRO) — the moment it's created. This page covers how that routing decision is made, how long each tier has to act, which alerts a single reviewer may close alone, and how an alert gets escalated or assigned to an individual reviewer.
Every number on this page — score bands, SLA hours, closure ceilings — is a default Shufti configures for your account if you don't specify your own, not a fixed system limit. They can be configured to your risk appetite and regulatory obligations; contact Shufti to change them.
How an Alert Reaches Its Tier
Routing is checked in a fixed order, first match wins:
Sanctions override. A confirmed or partial sanctions list match sends the alert straight to the MLRO, whatever it scored. The obligation attaches to the match itself, not to the size of the payment.
Score band. If there's no sanctions match, the alert's risk score (0–100) is matched against your account's configured bands, and the band decides the tier:
Band Default range Default tier Low 0–40 L1 Medium 41–70 L2 High 71–100 L3 — except a score of 91 or above goes to the MLRO instead
The SLA clock for the receiving tier starts at the instant the alert is created — not when it's first opened or assigned.
Service-Level Agreement (SLA) per Tier
| Tier | Default SLA | Starts counting from |
|---|---|---|
| L1 | 24 hours | Alert creation |
| L2 | 24 hours | Alert creation |
| L3 | 48 hours | Alert creation |
| MLRO | 72 hours | Alert creation |
Three behaviours worth knowing before you rely on this clock operationally:
Escalating a tier does not grant a fresh window. The deadline is recalculated from the alert's original creation time against the new tier's SLA — not from the moment of escalation. An alert escalated two or three times still can't outrun its SLA by restarting the clock each time.
Example: an alert created on Monday at 09:00 lands on L1 (24-hour SLA), so it is due Tuesday at 09:00. If it is escalated to L3 (48-hour SLA) on Monday at 17:00, it becomes due Wednesday at 09:00 — 48 hours from creation — not Wednesday at 17:00. Escalated to L2 instead (also 24 hours), it would stay due Tuesday at 09:00. If the new tier's window has already passed, the alert is overdue straight away.
Waiting on the customer can pause the clock, if your account allows it. Requesting information from the customer pauses the SLA only where pausing is enabled for your account; otherwise the clock keeps running while you wait.
Reopening a closed alert restores the time it had left, measured from the moment it reopens — it doesn't instantly breach for time spent closed, and it doesn't hand back a full fresh window either.
Who May Close an Alert Alone
A reviewer closes an alert within their own tier's limits:
| Tier | May close alone if | Default value ceiling |
|---|---|---|
| L1 | Score < 40 | ≤ €10,000 |
| L2 | Score < 40 | ≤ €50,000 |
| L3 | Any score | ≤ €250,000 |
| MLRO | Any score | ≤ €1,000,000 |
The value ceiling exists because score alone doesn't catch everything: a single rule can fire on a very large transfer and still score under a tier's score limit, and that shouldn't close on one reviewer's judgement regardless of score. These are the default ceilings Shufti configures when you don't specify your own, and they can be configured to match your transaction sizes.
Assignment Within a Tier
Each tier only sees its own alerts: an L1 reviewer's queue shows the alerts assigned to L1, not the full account-wide queue. Every alert carries a named Case Assignee.
To move an alert to a higher tier, a reviewer clicks Escalate Tier and fills in:
- Escalate To — the destination tier
- Assign To — the specific person on that tier who should take it
- A reason for the escalation
This puts the choice of who picks the alert up next in the escalating reviewer's hands. If you're setting up a new tier, make sure the reviewers who'll be escalating to it know who's on it, since they'll be naming that person directly.
Configuring Review Tiers in the Back Office
Tier membership comes entirely from your account's roles and permissions, not from a dedicated "Alert Queue team" screen. Five permissions control this product:
| Permission | What it grants |
|---|---|
kyt_alert_queue | Access to the Alert Queue screen itself. On its own it puts nobody on a tier. |
kyt_alert_l1 | Membership on the L1 tier |
kyt_alert_l2 | Membership on the L2 tier |
kyt_alert_l3 | Membership on the L3 tier |
kyt_alert_mlro | Membership on the MLRO tier |
To put a reviewer on a tier: grant them the matching permission, either directly on their sub-user or through a role they hold. Whenever a role's permissions change (or a permission is granted directly), every tier's full membership is recalculated from scratch and pushed upstream as a replacement, not a merge — so removing the permission from someone really does take them off the tier, rather than leaving a stale membership behind. A sub-user is counted either through a role or through a direct grant, never both at once.
These five permissions won't even appear as assignable options until your account has both Transaction Trust Monitoring and the Rule Builder enabled. That's an account-level setting Shufti turns on for you, not something you self-serve — if you don't see them in your roles screen, that's the first thing to check.
Before assigning any tier permission, open the Alert Queue screen once as the account's primary user. This is what activates your account's review tiers, so it should always be the first step when setting up a new client — do it before granting any kyt_alert_l1/l2/l3/mlro permissions, so every reviewer you configure lands on a tier that's already active.
The Alert's Status as It Moves Through Review
Knowing an alert's status makes it easy to read what's actually happening just by looking at the queue, without needing to open it:
| Status | What it means |
|---|---|
| Open | Sitting with its current reviewer, waiting to be worked. Every alert starts here. |
| Pending Info | On hold while waiting for the customer to respond to a request for information. The SLA clock may be paused here (see above). |
| Escalated | Moved to a higher tier. An alert can be escalated more than once; each escalation is recorded as its own event. |
| Closed | Finished, with a disposition of either False Positive or Resolved. |
A customer's reply brings a Pending Info alert back to Open on its own.
Escalating, Requesting Information, and Closing
The actions available on an open alert, at every tier, are:
- Escalate to a higher tier, with a reason — see Assignment Within a Tier above.
- Request information from the customer, which can pause the SLA if your account enables pausing.
- Close as False Positive or Close as Resolved — resolving closes the alert after investigation when no further action is required, with a documented resolution and justification. SAR/STR reporting is a separate workflow; an alert can be resolved without a filing.
See How It Works? for the full alert detail view (score, evidence, linked transactions, AI summary) and the regulatory reporting workflow.