Scope, stated plainly. This is workflow and evidence software. It is not a transaction monitoring engine, not a detection model and not a sanctions screening tool. It does not make compliance determinations, and it does not replace your BSA officer, your model validation or your institution's obligations under its own program.
The alert is raised in one system and worked in three others
A monitoring system produces alerts. What happens next, in most banks, is not a system at all. The alert is opened in the monitoring tool, the customer is researched in the core, the transactions are pulled into a spreadsheet, the narrative is written in a document, the approval is an email, and the case file is whatever the analyst remembered to save into a folder named after the alert.
Nothing in that sentence is a detection problem. It is a workflow problem, and it is the reason two banks running the same monitoring scenarios can have completely different exam outcomes. The detection was equivalent. The record of what was done about it was not.
What the triage layer has to do
Step 01
Take the alert as an item
Alerts arrive from the monitoring system as items with a type, a subject, a risk rating and the transactions that triggered them, rather than as a screen an analyst has to be logged into.
Step 02
Route on rules you set
By alert type, risk rating, entity, business line or language. A high risk correspondent alert does not sit in the same queue as a low value structuring alert, and neither waits for someone to notice it.
Step 03
Enforce the evidence set
Each alert type carries a required evidence list. The disposition action is not available until the list is satisfied, so an incomplete case cannot be closed and then discovered at exam time.
Step 04
Approve under segregation of duties
The analyst proposes a disposition and a different role approves it. The system refuses a self approval regardless of permissions, and logs the attempt.
Where the hours actually go
Alert volume is the number every vendor quotes and it is rarely the constraint. The constraint is the time between opening an alert and having enough in front of you to make a decision. When that assembly is manual, it dominates the day, and it is identical for every alert of the same type, which is what makes it automatable without touching a single detection threshold.
| Stage of an alert | Worked across four systems | Worked as one item |
|---|---|---|
| Assignment | Analyst picks from a shared list, or a lead allocates by hand | Routed on type, rating and business line at arrival |
| Context gathering | Manual lookups in the core, the CRM and prior cases | Subject, history and prior alerts attached to the item |
| Transaction review | Exported to a spreadsheet and annotated locally | Triggering transactions held on the item with the analyst notes |
| Narrative | Free text in a document, quality varies by analyst | Structured template per alert type, required fields enforced |
| Approval | Email to a manager, decision recorded in the reply | Maker-checker action, approver and timestamp on the record |
| The case file | Assembled from folders and inboxes when asked | One export, complete, with the policy version in force |
A worked example
Input
- ALERT-2026-04417 · Scenario: rapid movement of funds
- Subject: business account, opened 2024-11, MSB related
- Risk rating: high · Raised: 03 Sep 2026 06:12
- Triggering activity: 9 credits, 8 debits, 14 days
- Aggregate: $486,300 · Prior alerts: 2 (both closed)
Output
- HIGH RISK routed to Enhanced review, not the general queue
- AGE 0d clock starts at raise time, SLA target 5 business days
- Prior alerts and dispositions attached automatically to the item
- Required evidence: source of funds, expected activity, 2 prior dispositions, EDD note
- Disposition blocked until the evidence list is complete, then maker-checker
Escalation to a SAR decision, and where we stop
When an alert escalates, the workflow escalates with it: a case that can hold several alerts, a longer evidence set, a different approval chain, and a deadline that is counted rather than remembered. What the software does is make sure the file is complete, the clock is visible and the approvals happened in the right order.
What it does not do is decide. Whether activity is suspicious, whether a filing is required, and what the narrative says are determinations made by your BSA officer under your program. Software that claims to make that call for you is describing a compliance risk as a feature. We package the decision, we do not make it.
Tuning, backlog and the two numbers that get confused
A false positive rate is a property of your scenarios and thresholds, and it is changed by tuning the monitoring system with model validation behind it. A backlog is a property of your throughput. They are different problems and they are constantly treated as one, usually by proposing a tuning exercise to fix a queue that is behind because triage takes forty minutes an alert.
- If alerts are mostly noise, that is a tuning and validation exercise in your monitoring system. Nothing on this page fixes it, and no vendor should promise a reduction without your data.
- If alerts are reasonable but the queue is behind, that is triage time and it is very fixable, because most of it is assembly rather than judgement.
- If dispositions are inconsistent between analysts, that is a required evidence and template problem, not a training problem.
- If exams find gaps in closed cases, that is an enforcement problem: the system allowed an incomplete case to close.
- If nobody can say how old the oldest open alert is, that is the first thing to fix, and it is a reporting change rather than a project.
What an examiner asks for, and how long it takes
The exam question is rarely about the model. It is a sample: pull these fifteen alerts from this period and show us what was done. The honest measure of a triage layer is how long that takes and whether the answer is the same for every one of the fifteen.
- 01Every alert raised in the period, with its disposition and the date it was reached.
- 02For a sampled alert, the complete file: evidence, notes, transactions, approvals, timestamps.
- 03The policy and rule versions in force at the time of the decision, not the versions in force today.
- 04The aging profile of open alerts, and the escalation record for anything past its target.
- 05Evidence that the person who approved was not the person who prepared.
Each of those is a filtered export when alerts are items in a system with an audit trail, and a multi day reconstruction when they are folders and inboxes. That difference is the entire argument for this layer.
How this sits with the rest of the program
Monitoring is one queue among several that a compliance function runs. The onboarding and periodic refresh queues are covered in KYC automation software, the program level framing is in AML compliance software, and the generic mechanics of queues, SLAs and maker-checker are in compliance workflow automation. If you are selecting a vendor, AML software for banks is the buyer guide, and the anti money laundering program post is the background reading.
Questions about bsa aml monitoring software
Is this a transaction monitoring system?
No, and it is important that it is not sold as one. It does not score transactions, does not raise alerts and contains no detection scenarios. It takes the alerts your monitoring system produces and runs the queue, the evidence and the audit trail around them.
Will it reduce our false positives?
It cannot, and any vendor promising that without your data is guessing. False positives come from scenarios and thresholds in the detection layer. What this reduces is the time each alert takes to work and the inconsistency between analysts.
Does it decide whether to file a SAR?
No. Determinations are made by your BSA officer under your program. The system makes sure the file is complete, the deadline is visible and the approvals happened in the right order.
How do alerts get in?
The day one path is a scheduled export from your monitoring system, ingested as items with type, subject, rating and triggering transactions. Where an API exists it can be configured as a source, but nothing waits on that.
Can we keep our existing disposition codes?
Yes. Alert types, disposition codes, required evidence sets, SLA targets and approval chains are all configuration. The one thing that is not configurable is the ability to switch off the audit trail.