AML transaction monitoring: the process, alert tuning, and the evidence examiners ask for
Transaction monitoring is usually framed as a detection problem: catch the suspicious activity. At exam time it turns out to be an evidence problem: show why each alert was closed, under which rule version, on what basis. Here is the end-to-end process, how tuning works, and how to keep the record that answers those questions.
What AML transaction monitoring is
AML transaction monitoring is the ongoing review of customer transactions against scenarios designed to surface potentially suspicious activity: structuring below reporting thresholds, rapid movement of funds through an account, transaction patterns inconsistent with the customer's stated profile, activity touching higher-risk jurisdictions, and dozens of similar typologies. It is the post-onboarding half of an AML program. KYC establishes who the customer is at the door; monitoring watches what the customer actually does afterward, for as long as the relationship lasts.
In the US, transaction monitoring sits inside the BSA/AML program a regulated institution is required to maintain, and it feeds the suspicious activity reporting obligation: when monitoring surfaces activity that meets the reporting standard, a SAR is filed with FinCEN. Other jurisdictions run the same loop under different names and filing formats. The mechanics below are described in US terms, but the process, and the evidence problem inside it, are the same shape everywhere.
Most fintechs do not build detection themselves. They run a monitoring vendor, Unit21, Sardine, or one of their peers, that executes the rules and produces the alerts. That is a sensible division of labor, and nothing in this article suggests changing it. The part that stays with you regardless of vendor is the decision layer: what your team did with each alert, and whether you can prove it later.
The end-to-end process
However the tooling is arranged, the flow runs through the same stages.
Scenarios and rules. The monitoring system evaluates transaction data against a library of scenarios, each with thresholds and parameters: aggregate cash over a window, velocity of transfers, deviation from expected activity, and so on. Some programs layer statistical or machine-learning models on top of rules; the models change how alerts are scored and prioritized, not what happens after one fires. The scenario library and its thresholds are themselves a governed artifact, which matters later.
Alerts. When activity trips a scenario, the system generates an alert. Alert volume is the operational reality of every monitoring program: in most programs, the large majority of alerts turn out to be false positives, which is why triage discipline and tuning exist. An alert is not an accusation; it is a flag that a human, or a documented process, must resolve.
Triage. An analyst reviews the alert against the customer's profile and history. Most alerts close here as false positives, and this is the step examiners probe hardest, because a closed alert is a decision: someone concluded the activity was not suspicious. That conclusion needs a documented rationale, not just a status change. "Closed, activity consistent with customer's stated business, see attached history" survives review; "closed" alone does not.
Case. Alerts that cannot be dismissed escalate to a case. The investigation widens: related accounts and counterparties, prior alerts on the same Subject, KYC file, adverse media, and whatever else the pattern warrants. Cases often merge multiple alerts on the same Subject into one investigation, and the file that results is the raw material for the filing decision.
SAR decision. The case ends in a decision: close with a documented rationale, or file. Both outcomes are decisions an examiner may ask about, and the decision not to file is scrutinized at least as closely as the decision to file. Who decided, on what evidence, under which policy, is the record that has to exist either way.
Filing and follow-up. If the decision is to file, the SAR narrative is drafted, reviewed, and submitted within the required window, and the supporting documentation is retained. Monitoring of the Subject typically continues, with follow-up reviews on a defined cadence if the activity persists. For what the narrative itself needs to contain, see what examiners look for in a SAR narrative; for a worked example of the pipeline from a crypto vendor's alert to a filed SAR, see from Chainalysis alert to SAR.
The defensibility problem is bigger than the detection problem
Detection is what monitoring programs are designed around, and it is largely a solved procurement problem: capable vendors exist at every stage and price point. The problem that stays unsolved after the vendor is live is defensibility, because an examination is not a review of your detection logic in the abstract. It is a review of specific decisions.
The questions arrive in a recognizable shape. Why was this alert closed? Who closed it, and what did they look at? Which version of the rule generated it, and what was the threshold at the time? When you changed that threshold in March, what analysis supported the change, and who approved it? Show us every alert on this Subject across the life of the relationship, and the disposition of each one.
The operating principle behind all of them is blunt: if it is not documented, it never happened. An analyst may have made exactly the right call on an alert, but if the rationale was never written down, or was written into a vendor console the team has since migrated off, the program cannot demonstrate it. And the answers rarely live in one system. The alert is in the monitoring vendor, the KYC file is in another platform, the case notes are in a case manager or a spreadsheet, the rule-change approvals are in email. Reconstructing one Subject's history across that sprawl is the slow, error-prone work that makes exam prep a project instead of a query. The patterns that prevent it are covered in examiner-ready audit trail patterns.
Alert tuning, and the paper trail around it
Tuning is the periodic recalibration of scenarios so the program surfaces genuinely suspicious activity without drowning analysts in false positives. Left untuned, a rule set drifts in one of two bad directions: thresholds too tight produce alert backlogs the team cannot clear, and thresholds too loose produce coverage gaps the program cannot see. Neither failure announces itself; both show up in an exam.
A defensible tuning cycle has a recognizable structure, even though the specifics vary by program:
- Measure per scenario. Alert volume, false-positive rate, and SAR yield, scenario by scenario, so the conversation is about evidence rather than impressions.
- Test proposed changes against history. Above-the-line analysis checks what the current threshold catches; below-the-line analysis samples activity just under the threshold to check what a change would miss. Loosening a rule without below-the-line evidence is the change examiners challenge first.
- Govern the change. Material threshold changes go through a documented approval, with the analysis attached, an approver named, and an effective date recorded.
- Version, never overwrite. The old threshold and the new one both remain on record, so any historical alert can be read against the rule as it stood when the alert fired.
That last point is where tuning and defensibility meet. An alert closed in January was closed under January's rules. If the scenario was retuned in March and the program only retains the current configuration, the January disposition can no longer be evaluated on its own terms, and a look-back becomes reconstruction from email archives. Rule versioning is what keeps every past decision reviewable as a point-in-time fact.
One record per Subject, beneath the monitoring stack
FinQub is the single source of truth for fintech risk decisions, and transaction monitoring is one of the decision streams it records. Your monitoring vendor stays: a team running Unit21 or Sardine keeps running it, and the detection keeps happening there. What changes is where the decisions land.
Every alert disposition lands on the Subject. Each alert, its triage outcome, the analyst's rationale, and any override are attached to one record per Subject, alongside the KYC, KYB, sanctions, and fraud signals from the rest of the vendor stack. The question "show us every alert on this customer and what you did with each" becomes one query, not an assembly job across consoles.
Every decision is pinned to a policy version. Dispositions are recorded against the rule and policy version in force at the time, so a January closure reads against January's thresholds no matter how many tuning cycles have run since. Threshold history is versioned by construction, which is precisely the artifact the tuning questions ask for.
The exam response is a query, not a project. Because the trail accumulates continuously, look-backs and examiner requests are exports from a record that already exists, rather than reconstructions built under deadline.
A defensibility checklist for transaction monitoring
- Every closed alert carries a written rationale, not just a status.
- Each disposition is tied to the rule version and thresholds in force when the alert fired.
- Threshold and scenario changes are versioned, approved, dated, and never overwritten.
- Tuning runs on a defined cadence, with above-the-line and below-the-line analysis retained.
- SAR decisions, including decisions not to file, are documented with decider and evidence.
- All alerts, cases, and dispositions for any Subject can be produced from one record, on one query.
- The decision record survives vendor migrations, because it lives beneath the vendor, not inside it.
Frequently asked questions
What is AML transaction monitoring?
AML transaction monitoring is the ongoing review of customer transactions against scenarios and rules designed to surface potentially suspicious activity, such as structuring, rapid movement of funds, or activity inconsistent with a customer's profile. It is the post-onboarding half of an AML program: KYC establishes who the customer is, and transaction monitoring watches what they actually do. In the US it is a pillar of a BSA/AML program, and the alerts it produces feed the SAR decision process.
What does the AML transaction monitoring process look like end to end?
Scenarios and rules run against transaction data and generate alerts. Analysts triage each alert, closing false positives with a documented rationale and escalating the rest to a case. Case investigation gathers the customer's history, related Subjects, and supporting evidence, and ends in a decision: close with rationale, or file a SAR. If a SAR is filed, the narrative is drafted, the filing is submitted to FinCEN (or the local FIU), and monitoring of the Subject typically continues with follow-up reviews. Every step of that chain is expected to leave a record.
How does transaction monitoring rules tuning work?
Tuning is the periodic recalibration of scenario thresholds and parameters so the rule set surfaces genuinely suspicious activity without burying analysts in false positives. A typical cycle looks at alert volumes, false-positive rates, and SAR yield per scenario, tests proposed threshold changes against historical data (above-the-line and below-the-line analysis), and puts material changes through governance approval before they go live. The cadence varies by program; what matters to examiners is that tuning happens on a defined schedule, follows a documented methodology, and each change is approved and dated.
What documentation do examiners expect around threshold changes?
For each change, examiners generally want to see what the threshold was before and after, the analysis that justified the change, who approved it, when it took effect, and what the impact was on alert volume and coverage. They also probe the other direction: if a rule was loosened, they may ask whether any activity that would have alerted under the old threshold went unreviewed. That is why threshold history needs to be versioned, not overwritten, and why each alert disposition should be tied to the rule version that produced it.
Does FinQub replace our transaction monitoring vendor?
No. Your monitoring vendor, whether that is Unit21, Sardine, or another platform, keeps generating and scoring alerts. FinQub is the record beneath the stack: every alert, disposition, override, case decision, and policy version lands on one record per Subject, alongside the KYC, sanctions, and fraud signals from the rest of your vendors. The detection stays where it is; the defensible decision record is what FinQub adds.
The monitoring stack you have keeps doing the detecting. FinQub is the record of what you decided beneath it: every alert disposition, override, and policy version, on one record per Subject. See the audit-trail patterns examiners accept, walk the pipeline in from alert to SAR, or book a short walkthrough below.