Alerts, cases and reporting
Decisions that need a person become alerts, and so do screenings that find a potential match. An analyst works the alert and proposes how to close it, and a second person approves. That part is built. Cases, which group alerts into an investigation, and reports to your FIU are planned and described further down.
Alerts
A review or block decision goes on an alert. Alerts are grouped by source: while a customer has an alert that is open or in_review, their next review and block decisions join it instead of raising new ones. The alert counts them in occurrences and points at the highest-scoring one. One busy wallet doesn't fill the queue.
An alert starts at medium priority for a review and high for a block, and a later block raises it to high.
| Status | Meaning |
|---|---|
open | Waiting for an analyst |
in_review | Assigned and being worked |
pending_closure | An analyst proposed a disposition and it's waiting for a second person |
closed | A second person approved the closure |
Once an alert is pending closure or closed, it takes no more decisions. New activity from that source starts a new alert.
Alerts from screening
A screening that comes back potential_match raises its own alert. It's high priority if any match is on a sanctions list, and medium otherwise. In the queue it shows the best match score and one reason per match, and its event type is screening.
An analyst works it on the Screening screen, one match at a time:
- True match. It's the person on the list. This counts at once, and the alert stays open so someone acts on it.
- Need more info. Can't tell yet. This counts at once, and the match stays open.
- False positive. It's someone else. A second person has to approve this before it counts.
When every match is cleared and approved, the alert closes by itself as false_positive. Nobody has to close it by hand. A screening alert can also be closed the usual way, with a disposition and a second approval.
Working an alert
Triage
An analyst opens the Alerts queue in the dashboard, picks an alert, and assigns it to themselves. They see the score, the rules that fired and why, and the event behind it.
Notes
The analyst records what they checked and what they found as notes on the alert. Notes are kept with the author's key and a timestamp.
Propose a disposition
The analyst asks to close the alert as false_positive, escalated or reported. The alert moves to pending_closure.
Second approval
A reviewer, signed in with a different API key, approves or rejects. Approving closes the alert. Rejecting sends it back to in_review. The analyst who asked can't approve their own closure.
Every status change, assignment, note and closure step is written to the audit log with the key that made it. The alerts API does the same things as the dashboard.
Cases
reported disposition records the decision to report, but nothing is drafted or filed.A case groups related alerts with the evidence: transactions, linked entities, attachments, notes and a written narrative. The narrative is a plain account of what happened and why it's suspicious. Sentinel drafts the first version from the evidence and the analyst edits it.
The analyst proposes an outcome: close, keep monitoring, or report. A reviewer must approve it. The analyst can't close a case alone. Once closed, a case is read-only.
A case, end to end
Here is how one suspicious transfer will be followed through the console once cases and reporting exist.
Triage
An analyst opens the Alerts queue. A high-priority alert sits near the top, with its score, the rules that fired and a summary.
Look wider
On the Entities screen, the Network graph shows the wallet linked to 23 senders (most of them first-time), a wallet opened three days ago on the same phone, a cash-out agent where 9,800 was withdrawn, and another alert about that same agent. It looks like a mule network: victims' money collected in one wallet, passed on and cashed out fast.
Freeze
To stop more money leaving, the analyst freezes the wallet. Sentinel tells the operator to block outgoing transfers and cash-outs. Incoming money still arrives so the trail stays visible. The customer sees a generic error, and the reason goes into the audit log.
Open a case
The analyst groups the two alerts into a case, attaches the 61 transactions and a letter from the operator's fraud desk, and edits the narrative.
Propose an outcome
The analyst proposes "close as reported" and sends the case for review.
Second approval
On the Four-eyes review screen, a reviewer sees the proposal, what will happen if they approve, and exactly what changed since they last looked. They tick four checks: the narrative supports suspicion, details match KYC, attachments are readable, and there's no conflict of interest. Then they confirm in the Approve and file dialog.
File
Sentinel validates the STR against goAML's rules and submits it to your FIU. When the FIU's receipt comes back, it's stored on the case. The case closes and becomes read-only, and a PDF copy of the filed report is kept.
Fix a rejection
Sometimes goAML bounces a report, for example for a missing date of birth. The Filing rejected screen shows which field failed, links to where to fix it, and shows the deadline. The analyst fixes it and resubmits.
Prove it later
At the end of the quarter, the compliance lead builds an evidence pack. Every action above is in the audit log.
Reporting
- STRs are drafted from a case, validated against goAML's schema and rules before submission, and filed with your FIU. The FIU's receipt is stored on the case.
- CTRs are generated in batches from monitored cash events above the threshold you configure.
- Rejections come back with the exact fields that failed. New checks are added to the validator so the same mistake fails locally next time.
- Evidence packs combine policies, the rule inventory, alert statistics, case outcomes and filings into one signed PDF for regulators and partners.