AML Transaction Monitoring: How It Works, Process, Rules & Red Flags

Transaction monitoring sits at the centre of many AML compliance programs, yet it is often conflated with ongoing monitoring, treated as though a specific software platform is legally required, or reduced to "watch for red flags" without a defined process behind it.

This article sets out how AML transaction monitoring actually works end-to-end: what data it needs, how rules and scenarios generate alerts, how alerts are investigated and closed or escalated, how monitoring is tuned and tested, who should be accountable for it, and how Canadian and U.S. regulatory expectations differ in practice.

What Is AML Transaction Monitoring?

AML transaction monitoring is the analysis of transactional activity — deposits, withdrawals, transfers, currency exchanges, virtual asset movements — against a set of rules, scenarios, and behavioural baselines designed to surface activity that may warrant investigation. Monitoring can look at a single transaction, a sequence of transactions, or activity across a period of time.

The output of transaction monitoring is an alert: a system- or analyst-generated flag indicating that a transaction or pattern deviates from an expected threshold, rule, or customer profile. An alert is not a finding of wrongdoing. It is the starting point of a review that may end in the alert being closed with no further action, escalated internally, or reported to FINTRAC or FinCEN as a suspicious transaction or suspicious activity.

Transaction Monitoring vs Ongoing Monitoring

These two terms are often used interchangeably, but they are not the same thing, and conflating them creates real compliance risk.

Transaction monitoring is focused specifically on analysing transactional activity — individual transactions or patterns of transactions — to detect unusual or suspicious behaviour that may need to be reported.

Ongoing monitoring is broader. Under FINTRAC's guidance, ongoing monitoring is a process that reporting entities must develop to review all the information they hold about a client with whom they have a business relationship. Its purposes include detecting suspicious transactions, keeping client identification and beneficial ownership information current, reassessing a client's risk level, and determining whether the client's transactions and activities remain consistent with what the reporting entity knows about them and its risk assessment of that client. Ongoing monitoring is a defined obligation under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA) and its regulations. Reporting entities must conduct ongoing monitoring of the business relationships they establish, with the frequency and intensity informed by risk.

In practice, transaction monitoring is one of the tools that supports ongoing monitoring — it is how many reporting entities detect the suspicious transactions that ongoing monitoring is partly designed to surface. But ongoing monitoring also covers things transaction monitoring does not, such as periodically refreshing identification information and reassessing client risk. A business can meet its ongoing monitoring obligation without necessarily deploying an enterprise transaction-monitoring platform, particularly where transaction volume and risk are low — the frequency and intensity of monitoring should follow the entity's risk assessment.

Why Transaction Monitoring Matters

Transaction monitoring is one of the main mechanisms businesses use to identify activity that may require suspicious transaction review. Without a structured monitoring process, unusual activity is more likely to go unnoticed until a customer complaint, a law-enforcement request, or an examination finding surfaces it after the fact. Weak or absent monitoring is a recurring theme in FINTRAC enforcement actions and administrative monetary penalties, typically framed as gaps in the compliance program's ability to detect and report suspicious activity rather than as a standalone monitoring failure.

Real-Time vs Post-Transaction Monitoring

Monitoring generally falls into two operational models:

• Real-time (or near-real-time) monitoring screens a transaction before or as it is processed, which allows a business to hold, delay, or decline a transaction pending review. This is more common in payments and virtual-asset businesses where funds move quickly and irreversibly.
• Post-transaction (batch) monitoring reviews completed transactions on a scheduled basis — hourly, daily, or otherwise — comparing them against rules and behavioural baselines. This is more common where transaction volumes are lower or system integration is limited.

Neither approach is inherently more compliant than the other. The appropriate model depends on the product, the speed at which funds can be recovered or frozen, and the risk profile of the customer base.

How End-to-End AML Transaction Monitoring Works

A mature transaction-monitoring process typically follows this lifecycle:

1. Transaction data capture. Raw transaction data is collected from core systems — payment rails, ledgers, wallets, or banking cores.

2. Data normalization and enrichment. Data is standardized into a common format and enriched with customer, account, counterparty, and geographic information so that rules have the context they need to run accurately.

3. Rules and scenarios. Transactions are run against a library of rules and behavioural scenarios designed to detect specific typologies (see the table below).

4. Alert generation. A transaction or pattern that meets a rule's threshold or a scenario's logic generates an alert for review.

5. Initial review (triage). An analyst performs a first-pass check to confirm the alert is valid and gather the immediate context — customer profile, transaction history, and any prior alerts.

6. Investigation. Where the initial review does not resolve the alert, an analyst investigates further: reviewing counterparties, geography, transaction patterns, and any supporting documentation.

7. Escalation. Alerts that raise genuine concern are escalated to a senior analyst, the compliance officer, or the MLRO for a reporting decision.

8. Disposition. Every alert is closed with a documented rationale — no further action, enhanced monitoring, or escalation for suspicious transaction reporting consideration.

9. STR/SAR consideration. Where the facts, context, and indicators support reasonable grounds to suspect a money laundering or terrorist financing offence, the business moves into its suspicious transaction reporting process. This article does not cover STR narrative writing or filing mechanics in detail — see ComplyFactor's dedicated reporting content for that.

10. Documentation. Every step — the alert, the review, the evidence considered, and the decision — is recorded to support audit trail and regulatory examination.

11. Feedback and tuning. Patterns in false positives, missed activity, or investigator feedback are fed back into rule and scenario design.

12. Testing. Tuned rules and scenarios are validated before and after deployment to confirm they perform as intended.

This lifecycle is what most searchers mean by "end-to-end transaction monitoring" — a complete process rather than a single detection step.

What Data Should Feed Transaction Monitoring

Monitoring is only as good as the data behind it. Useful inputs typically include:

• Transaction-level data (amount, currency, timestamp, channel, transaction type)
• Customer identification and risk-rating data
• Account and relationship data (account age, product type, linked accounts)
• Counterparty data (name, institution, jurisdiction)
• Geographic data (originating and receiving jurisdictions, including high-risk jurisdictions)
• Historical alert and case data
• For virtual asset businesses: wallet addresses, blockchain analytics output, and exchange/counterparty risk scoring

Poor data quality — missing counterparty fields, inconsistent customer identifiers, or unmapped product types — is one of the most common root causes of both false positives and missed detection.

How AML Monitoring Rules and Scenarios Work

It is useful to separate several concepts that are often blurred together:

A common and important error is treating an internal monitoring threshold as though it were a regulatory reporting threshold. They serve different purposes: a monitoring threshold exists to prompt a look; a reporting threshold exists to create a mandatory filing obligation once met, independent of whether the transaction is suspicious.

Common rule and scenario types include static (fixed) rules, behavioural rules that compare a customer against their own history, peer-group comparisons, velocity rules (frequency of transactions over a period), cumulative-activity rules, and geographic-risk rules layered on top of customer risk ratings.

Illustrative Monitoring Scenarios

These examples are illustrative starting points, not a prescriptive regulatory checklist. Actual rule and scenario design should be based on a business's own risk assessment, products, and customer base.

Alert Investigation: What Happens After an Alert Fires

An alert is the beginning of a review, not a conclusion. A practical investigation workflow looks like this:

1. Validate the alert. Confirm the data underlying the alert is accurate and the rule fired as intended.
2. Review the customer profile. Check occupation, stated purpose of the relationship, expected activity, and risk rating.
3. Review transaction history. Look at the pattern over time, not just the transaction that triggered the alert.
4. Check counterparties, geography, and behaviour. Assess whether counterparties or corridors involved are known risk factors.
5. Consider previous alerts. Repeat alerts on the same customer may indicate an emerging pattern even where each individual alert seemed minor.
6. Gather additional information where appropriate. This may include open-source checks or requesting information from the customer, consistent with the business's risk-based approach.
7. Document findings. Record what was reviewed and why the conclusion was reached.
8. Close, escalate, or investigate further. Every alert needs a clear, documented outcome.
9. Consider suspicious transaction reporting separately. Where reasonable grounds to suspect exist, the matter moves into the STR/SAR process — a distinct workflow with its own field-level and narrative requirements not covered here.

A recurring weakness in compliance programs is closing alerts with a one-line rationale such as "reviewed, no issue" with no supporting detail. Examiners and independent auditors consistently test whether documented rationale actually supports the disposition reached.

False Positives and Tuning

A high volume of false positives — alerts that, on investigation, do not represent genuine risk — is one of the most common operational problems in transaction monitoring. Common causes include:

• Overly broad scenarios that do not account for legitimate business patterns
• Thresholds set too sensitively for the customer segment involved
• Thresholds set too loosely, which creates a different problem: missed detection
• Duplicate alerts from overlapping rules covering the same underlying activity
• Poor data quality feeding inaccurate rule triggers
• Scenario overlap where multiple rules fire on the same transaction for related reasons

Tuning is the process of adjusting rules and scenarios — thresholds, logic, or scope — based on investigation outcomes, data quality findings, and changes in products or customer base. Effective tuning includes documented change control (who approved the change and why), validation of the tuned rule before full deployment, and post-implementation testing to confirm the change had the intended effect without creating a new detection gap.

Reducing false positives should not be treated as the sole objective of tuning. A monitoring program that eliminates alerts by loosening rules indiscriminately trades a false-positive problem for a detection-effectiveness problem. The goal is better-targeted detection, not fewer alerts for their own sake.

Monitoring Red Flags

The scenario table above describes how rules and typologies are designed. The indicators below are different: behavioural and investigative signals an analyst may notice during review that a rule may not explicitly capture. As with any indicator, context determines whether it warrants escalation — none of these is proof of criminal conduct on its own.

Governance: Who Should Own What

Transaction monitoring governance works best when responsibilities are clearly assigned and documented — actual structures will vary by business size, risk profile, and operating model.

This division of responsibilities maps onto the same governance logic ComplyFactor has covered in its Three Lines of Defense content — operational ownership, compliance oversight and challenge, and independent testing are distinct functions and should not be collapsed into one role, particularly as a business grows.

Testing Transaction Monitoring Effectiveness

Testing effectiveness is different from day-to-day alert review. Useful areas to assess include:

• Scenario coverage relative to the business's own risk assessment
• Data completeness and quality feeding the monitoring system
• Alert quality (are alerts well-supported and actionable, or noisy)
• False-negative risk (are known typologies actually being detected)
• False-positive rate and trend over time
• Consistency of investigation and escalation decisions across analysts
• Alert backlog and ageing
• Whether tuning changes were documented and validated
• Remediation tracking on prior findings

There is no single universal regulatory KPI or numeric threshold that defines an "acceptable" false-positive rate or alert-ageing target — these should be defined by the business based on its own risk profile and refined over time, not treated as fixed industry benchmarks.

Manual vs Automated Monitoring

Whether monitoring should be manual, automated, or a hybrid depends on:

• Transaction volume
• Product and channel complexity
• Size and diversity of the customer base
• Geographic exposure
• Overall risk profile
• Availability and quality of underlying data

A smaller or lower-volume MSB may use a documented manual or hybrid monitoring process where it can demonstrate adequate risk-based coverage, consistency, recordkeeping, and timely escalation. As transaction volume, product complexity, or customer risk increases, manual review typically becomes harder to sustain consistently, and greater automation becomes the more practical way to maintain that same coverage — not because a specific platform is mandated, but because manual capacity has limits. Neither approach is inherently compliant or non-compliant; the standard is whether the chosen approach is reasonable and risk-based for that specific business, not whether it matches what a larger competitor uses.

AML Transaction Monitoring in Canada: FINTRAC Expectations

FINTRAC's compliance program requirements are risk-based: reporting entities must have a documented risk assessment, and their controls — including the intensity of monitoring — should be commensurate with the risks identified. Building on the ongoing monitoring obligation described above, reporting entities must conduct ongoing monitoring of the business relationships they establish, with the frequency and intensity of that monitoring informed by risk, and enhanced measures required for clients rated high risk. FINTRAC's guidance gives examples of enhanced measures, such as reviewing high-risk transactions on an approved schedule, generating more frequent reports on high-risk activity, and setting business limits that trigger mandatory review.

FINTRAC does not prescribe a specific transaction-monitoring software product or a mandatory scenario library. Its guidance references "new technologies" — giving transaction monitoring systems as one example — as something a business may adopt, not as a universal requirement. What is legally required is the underlying ongoing monitoring obligation and the risk-based compliance program that supports it; how a business chooses to detect suspicious activity within that framework is a design decision informed by its own risk assessment.

Where transaction monitoring identifies activity meeting the threshold of reasonable grounds to suspect a money laundering or terrorist financing offence, the business's obligation shifts to suspicious transaction reporting — a separate process governed by its own timing and content requirements. See ComplyFactor's FINTRAC Reporting Requirements hub for detail on report types, thresholds, and deadlines.

AML Transaction Monitoring Under U.S. BSA/AML Requirements

In the United States, money services businesses are required under 31 CFR § 1022.210 to establish and maintain an anti-money laundering program that is risk-based — commensurate with the risks posed by the MSB's location, size, and the nature and volume of its services. The program must provide for training on detecting the transactions the MSB is required to report, and for independent review to test the program, with the scope and frequency of that review also commensurate with risk. Separately, MSBs are generally required to file Suspicious Activity Reports under 31 CFR § 1022.320.

Neither rule mandates a specific transaction-monitoring technology or a fixed scenario set for MSBs. Detailed transaction-monitoring system expectations set out in supervisory material such as the FFIEC BSA/AML Examination Manual were developed primarily for banks and other institutions subject to federal banking supervision; they should not be applied to MSBs as though they were binding MSB requirements. MSBs and other non-bank reporting entities should build monitoring programs that are proportionate to their own risk profile and satisfy their own applicable rule, rather than importing bank-specific examination expectations wholesale.

Common Governance Failures in AML Transaction Monitoring

The section above addresses technical causes of false positives and poor tuning. The failures below sit at the governance and operational level, and are just as commonly cited in FINTRAC examination findings and administrative monetary penalty decisions:

• Alert backlogs. A growing queue of unreviewed alerts delays escalation and reporting decisions, and can mask emerging patterns that only become visible when alerts are reviewed together rather than in isolation.
• Closing alerts without documented rationale. A disposition with no supporting detail cannot be tested by an examiner, an independent auditor, or the business's own quality assurance process.
• Uniform monitoring intensity across materially different risk segments. Applying the same review depth to low-risk and high-risk relationships understates the enhanced measures high-risk clients require.
• Unclear ownership or weak escalation governance. When it isn't clear who approves scenario changes, who has final say on a disposition, or who escalates to the MLRO, decisions become inconsistent across analysts and over time.
• Failure to act on prior testing or audit findings. Repeated recommendations from an effectiveness review or internal audit that are not remediated point to a governance gap independent of how well the monitoring rules themselves are designed.

Frequently Asked Questions

What documentation should be retained when a transaction-monitoring alert is closed?

At minimum: what triggered the alert, what information was reviewed (customer profile, transaction history, counterparties), the reasoning for the outcome reached, who made the decision, and the date. A closure note that states a conclusion without the supporting reasoning behind it is difficult to defend in an examination or independent test.

Should attempted or rejected transactions be included in transaction monitoring?

Attempted transactions that do not complete can still be relevant to detecting unusual behaviour or informing a suspicious transaction assessment, since the reporting regime itself treats attempted and completed transactions as related concepts. Whether and how a business's monitoring rules capture attempted transactions is a design decision that should be addressed explicitly in monitoring policies rather than left as a gap.

When should a transaction-monitoring scenario be reviewed outside the normal review cycle?

Common triggers include a material change in products or services, entry into a new customer segment or jurisdiction, findings from an independent test or audit, a pattern of related false positives or false negatives identified through investigations, or an update to the business's risk assessment.

Can monitoring rules differ by customer risk level, product, or channel?

Yes, and in most cases they should. A single rule set applied uniformly across a diverse customer base or multiple products tends to under-detect in higher-risk segments and over-generate alerts in lower-risk ones. Segmenting rules by risk level, product, or channel is a normal part of risk-based scenario design, not an exception to it.

What is a false negative in AML transaction monitoring?

A false negative is activity that should have generated an alert — because it matched a known typology or exceeded a risk-appropriate threshold — but did not, typically because of a coverage gap, a misconfigured rule, or a data quality issue. False negatives are harder to identify than false positives because, by definition, no alert was generated to prompt a review; they are usually found through targeted testing, sample-based quality assurance, or after-the-fact investigation.

When should monitoring findings trigger a customer risk-rating review?

When investigation reveals activity that is materially inconsistent with the customer's stated profile, involves new higher-risk counterparties or jurisdictions, or represents a pattern rather than a one-off event, that is a signal the customer's existing risk rating may no longer reflect current activity — not just a reason to close the individual alert.

Where Weak Transaction Monitoring Points to a Broader Problem

The governance failures described earlier are rarely isolated technology problems. They are usually symptoms of a compliance program that has outgrown its governance structure, or of oversight that has not kept pace with growth in transaction volume or product complexity. In that situation, the fix is rarely "buy a better tool" — it's revisiting who owns monitoring decisions, whether the compliance program has enough capacity to keep pace with the business, and whether the last independent test actually checked the things that matter.

ComplyFactor supports Canadian MSBs, fintechs, payment companies, and VASPs in that situation through AML Compliance Program development, Fractional Compliance Officer and Fractional MLRO support, and Independent AML Audit and effectiveness review services.

This article provides general compliance information and does not constitute legal advice. AML transaction-monitoring obligations vary by jurisdiction, sector, and risk profile. Businesses should confirm their specific requirements against current FINTRAC, FinCEN, or other applicable regulatory guidance, or seek advisory support.