From alert to decision: running an investigation queue that keeps up
Keep two queues with two jobs. Triage alerts quickly and label every one; open an investigation only when the evidence needs an owner, group it by customer, prioritise by risk and deadline, and close it with a recorded outcome and rationale.
Charles Archibong, Co-founder
· 5 min read
Key takeaways
- Alerts and investigations are different jobs: triage is fast and labelled, investigation is owned and evidenced.
- Group work by customer, so one person reviews one customer's behaviour instead of ten tickets.
- Prioritise by risk and deadline, and watch deadlines before they pass, not after.
- No alert or investigation should close without a labelled outcome and a written reason.
Run two queues with two different jobs. The alert queue is for fast triage: look at the evidence, decide whether it needs more work, and label the result. The investigation queue is for owned casework: one person, one customer, a deadline, and a recorded outcome with a reason.
Most queues fall behind because those jobs are mixed. Every alert becomes a mini-investigation, the same customer is reviewed by three people on the same day, and nothing records why an alert was closed. Separating the jobs, grouping by customer and making outcomes mandatory is what keeps a small team level with its workload.
What is the difference between an alert and an investigation?
An alert is a signal that needs triage. It says what happened and why the system raised it. An investigation (often called a case) is the record of work: an owner, evidence, a decision and a rationale.
Alert | Investigation | |
|---|---|---|
Created by | The monitoring engine, when an event scores at or above the review threshold | A person, when an alert needs an owner or more evidence |
Scope | One behaviour | One customer, possibly several alerts |
Target handling time | Minutes | Hours to days, depending on priority |
Ends with | A label: true positive, false positive or inconclusive | An outcome, a rationale, and possibly a report |
Myaza Cases & SAR Filing (investigation workflow and regulatory report drafting) follows this split. Alerts open automatically from Transaction Monitoring, and an investigation is opened from one or more alerts when the evidence needs an owner or an outcome. The investigations documentation describes both records.
How should alerts be grouped?
Group in two ways: repeat firings into one alert, and alerts into one investigation per customer.
Roll up repeat firings. When the same rule fires on the same customer five times in a day, the analyst needs one alert with an occurrence count, not five tickets. Myaza folds repeat firings of the same rules on the same customer into one alert and increases its occurrence count, which is also carried in the alert.updated webhook.
Investigate by customer, not by alert. A mule account usually trips several rules: velocity, rapid movement, many distinct senders. Reviewed separately, each alert looks borderline. Reviewed together, the pattern is clear. In Myaza, several alerts can be grouped into one investigation as long as they belong to the same customer, and more of that customer's alerts can be added while it is open. Keeping one customer per investigation also keeps the record clean for any report that follows.
A worked example: a wallet customer in Abuja triggers a velocity alert at 09:10, a smurfing alert at 11:40 and a rapid-movement alert at 14:05, each showing funds from many senders leaving within minutes to one outbound account. The first analyst who picks up any of the three opens one investigation, links all three, and assigns it to themselves. The other two alerts leave the triage queue at once.
How should work be prioritised?
Priority should come from risk, not from arrival order. A simple rubric keeps decisions consistent across analysts:
Priority | Typical triggers (illustrative) |
|---|---|
Critical | A BLOCK decision, a counterparty on a blocked list, a possible sanctions exposure |
High | Several rules firing together, a large value relative to the customer, a known typology such as pass-through |
Medium | A single rule with a moderate score and some supporting context |
Low | A single low-weight signal with little context |
Attach a deadline to each priority and publish the deadlines internally. The value of a deadline is that the team sees risk before it is missed. Myaza records a priority (LOW, MEDIUM, HIGH or CRITICAL) and a due time on each investigation, and sends case.sla_at_risk when the due time is approaching and case.overdue when it has passed. Route the first to the team lead, not the whole channel, so it prompts reassignment rather than noise. The alerts and investigations webhook reference lists the events and fields.
Two habits help a queue stay honest:
Assign at open. An unassigned investigation belongs to nobody. Make assignment part of opening one.
Escalate by status, not by message. If a case needs a senior reviewer, move it to an escalated status so the record shows it. A chat message leaves no trace in the file.
What does a good triage decision look like?
Triage should answer one question within minutes: does this need an owner? Give analysts a fixed sequence:
Read the reasons. Which rules fired, with what detail (for example, "amount 48000 > 10000")?
Check the customer's recent history and any open investigation.
Decide: clear it, attach it to an open investigation, or open a new one.
Record the label and a one-line reason.
Clearing is a real decision, not a shortcut. A false positive label with a reason ("regular payroll batch to known staff accounts") is useful evidence for tuning the rule later. An alert closed without a label is lost information.
How should an investigation be closed?
Separate resolving from closing, and require a rationale for both.
Resolving records the evidence-backed outcome. Myaza uses four outcomes:
Outcome | Use it when |
|---|---|
Cleared | The activity has a legitimate explanation, supported by evidence |
Confirmed | The activity is suspicious or fraudulent |
Escalated | A more senior reviewer or the MLRO must decide |
Inconclusive | The evidence does not support either conclusion |
Closing completes the operational work: account actions taken, customer contacted, report drafted if needed. Keeping the two apart lets a manager see cases that are decided but still need follow-up.
In Myaza, the outcome is written back to the customer's risk record, so a confirmed investigation raises the risk recorded against that customer. The rationale, actor and timestamps stay in the investigation's timeline, and a closed investigation can be reopened when new evidence appears. Every write is recorded in the organisation's audit log.
Be wary of "inconclusive" becoming a default. It is a legitimate outcome, but if a large share of investigations end that way, either the evidence available to analysts is thin or the rules raising the alerts are not specific enough.
How do you keep up when volume spikes?
Spikes usually come from a rule change, a product launch or a real attack. Handle each differently.
After a rule change, check whether one rule accounts for the spike. If so, review that rule rather than hiring your way through it.
After a launch, expect baseline-driven rules to be noisy until new customers build history. Consider a temporary lower weight, recorded with a review date.
During an attack, group aggressively. Bulk assignment and bulk disposition of clearly related, clearly legitimate alerts keep the team on the cases that matter. Myaza supports bulk actions on investigations, but every item still carries its own outcome and record.
A queue checklist
Alerts and investigations are separate queues with separate targets.
Repeat firings roll up into one alert; investigations are one customer each.
Priority comes from a written rubric, and every priority has a deadline.
Every investigation has an owner from the moment it opens.
Deadline warnings reach the team lead before a case is overdue.
No alert closes without a label; no investigation resolves without a rationale.
Outcomes feed back into customer risk and into rule tuning.
If you can answer "who owns this, by when, and why was it closed" for every item in the queue, the queue is under control.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
