Guide · AML monitoring

AML transaction monitoring: the complete guide

What ongoing AML monitoring requires beyond onboarding KYC, the three monitoring approaches, the vendor landscape, multi-vendor architecture, SAR filing workflow, and the 2024-26 shift to real-time.

Updated May 2026·12 min read

AML transaction monitoring is the ongoing process of inspecting financial activity for patterns that may indicate money laundering, terrorist financing, fraud, sanctions evasion, or other financial crime. It is the half of the AML program that runs continuously after onboarding KYC is complete — and it is where most fintechs and sponsor banks have the largest gap between what they have today and what examiners now expect.

This guide walks through what transaction monitoring actually requires under U.S. and EU regimes, the three architectural approaches (rules, ML, hybrid), the vendor landscape circa 2026, why multi-vendor architectures are increasingly common, the SAR filing workflow, the post-2024 shift toward real-time monitoring, and the evidence infrastructure that makes a transaction-monitoring program defensible during examination.

What AML transaction monitoring is

Transaction monitoring is the second pillar of the AML program. The first is customer identification and customer due diligence at onboarding (KYC, KYB, beneficial ownership). The second is ongoing monitoring of activity throughout the customer relationship to detect patterns that warrant investigation and, where appropriate, a suspicious activity report (SAR).

The activity types in scope include:

  • Account funding and withdrawal patterns — especially structuring (deposits or withdrawals just below the $10K CTR threshold).
  • Velocity — unusual frequency or volume of transactions relative to the customer profile.
  • Geographic patterns — transactions to or from high-risk or sanctioned jurisdictions.
  • Counterparty patterns — repeated transactions with the same counterparty, layering through unrelated parties, transactions with high-risk merchant categories.
  • Behavioral changes — sudden shifts in customer activity that don't match the established profile.
  • Sanctions screening — both at the transaction level (counterparty match) and ongoing rescreening of the customer base as sanctions lists evolve.

Each of these requires a rule, a model, or a human reviewer to flag activity for investigation. The investigation either dismisses the alert (with documented rationale) or escalates to a SAR filing within 30 days of detection (60 if a continuing-activity SAR follow-up).

The three monitoring approaches

Rules-based monitoring

Hand-authored rules expressed against the transaction stream — "flag if more than $9,500 in cash deposits in a 24-hour rolling window", "flag if more than five transactions to high-risk countries in a week", "flag if structured deposits to a new business account." Predictable, explainable to examiners, and easy to audit. The trade-off is high false-positive rates (often 90-95% of alerts are dismissed) and the operational cost of running through them.

ML-based monitoring

Models trained on labeled historical data to score transactions for suspicion likelihood. Better at catching novel patterns rules miss; harder to explain to an examiner why a particular alert fired. Practical only at sufficient volume to train and tune the model. Most regulated entities use ML alongside rules, not as a replacement.

Hybrid monitoring

Rules carry the explainable backbone; ML adds a risk-scoring overlay that prioritizes alert review and surfaces patterns rules don't catch. This is the dominant approach in 2026. A typical hybrid stack: rules generate alerts, ML scores them by likelihood-of-true-positive, and the highest-scoring alerts go to investigators first.

The vendor landscape

The AML transaction monitoring vendor landscape circa 2026 has roughly five segments, with notable players in each.

Modern, fintech-native platforms

  • Unit21. Workflow-and-monitoring platform with strong rule authoring, case management, and integrations to common fintech data sources. Common at growth-stage fintechs and BaaS programs.
  • Hummingbird. SAR filing and case management as the strongest features, with monitoring integrated. Strong at scaling investigation operations.
  • Sardine. Risk-and-fraud platform that increasingly covers AML monitoring. Strong device and behavioral signals; less mature at the SAR/case management layer than Unit21 or Hummingbird.
  • Hawk:AI. European-origin, strong on explainable ML and PSD2/PSD3 alignment; growing U.S. footprint.

Established, broader platforms

  • ComplyAdvantage. Originally a sanctions-screening platform; has expanded into transaction monitoring with strong screening data quality.
  • NICE Actimize. Enterprise platform widely used at large banks; expensive and heavyweight for fintech use.
  • Oracle FCCM, SAS AML. Enterprise legacy platforms. Rare in fintech, common at large banks.

Sanctions-specific

  • ComplyAdvantage, Refinitiv World-Check, Dow Jones Risk & Compliance. Used as the underlying data source for sanctions screening regardless of the broader monitoring platform.

Multi-vendor architecture

A growing pattern, especially at fintechs that operate across multiple sponsor banks or jurisdictions, is to use multiple AML monitoring vendors at the same time:

  • Specialization by category. One platform for card transactions, another for ACH and wires, another for crypto on-ramps. Different vendors have meaningfully different strengths in each category.
  • Geographic specialization. EU-focused vendors (Hawk:AI, ComplyAdvantage) have stronger native PSD2/PSD3 alignment; U.S.-focused vendors (Unit21, Hummingbird) have stronger BSA/SAR workflow integration.
  • Resilience. A single-vendor failure in monitoring doesn't mean missed alerts if a parallel vendor is also screening.

The architectural challenge with multi-vendor AML is that the case management and SAR filing has to be unified — a customer with alerts at two vendors needs one case, not two. This is where AML orchestration becomes valuable: the monitoring platforms produce alerts; an orchestration layer consolidates them by customer, deduplicates, routes to investigators, and feeds the unified evidence record.

The SAR filing workflow

The end-to-end SAR workflow, in U.S. terms (FinCEN), proceeds as follows:

  • Detection. A monitoring rule or ML score triggers an alert. The 30-day SAR clock starts on the date of detection.
  • Triage. First-level analyst reviews the alert against the customer's history and disposition guidance. Most alerts are dismissed at this stage with a brief written rationale.
  • Investigation. Alerts not dismissed are assigned to an investigator who pulls the complete customer file — onboarding, all transactions, all prior alerts, all communications — and develops the narrative.
  • Decision. The investigator recommends file or no-file. The BSA Officer (or designee) makes the final call.
  • Filing. If file: complete the FinCEN SAR form within 30 days of detection. The narrative section is the substantive content; the structured fields capture parties, amounts, dates.
  • Continuing activity. If suspicious activity continues, file a continuing-activity SAR every 90 days for as long as activity warrants.
  • Recordkeeping. The supporting file — transactions, alerts, investigation notes, decision documentation, the filed SAR — is retained for five years and produced on demand to FinCEN, examiners, or law enforcement.

The shift to real-time

Transaction monitoring historically ran in daily or hourly batches because that was sufficient for examiner expectations and operationally manageable. Three forces are pushing the cadence toward real-time as of 2026.

  • Faster payment rails. Instant payment systems (FedNow, RTP, SEPA Instant, UK Faster Payments) settle in seconds. Fraud and money-laundering schemes built around faster rails specifically exploit the gap between transaction execution and detection. Real-time monitoring closes that gap.
  • Sponsor-bank continuous monitoring. Post-Synapse, sponsor banks now expect real-time visibility into fintech AML metrics — alert volumes, dispositions, rule firing rates. Daily batch reporting is no longer adequate.
  • Examiner expectations. Examiners increasingly ask why a clearly-suspicious transaction was not blocked at execution rather than flagged after the fact.

Real-time monitoring requires re-architecting the alert pipeline. Rules and ML scoring need to run on the transaction execution path with sub-second latency budgets. Integration with payment systems and ledgers needs to support pre-authorization holds. Investigation workflows need to handle live alerts that may need same-shift dispositions. Most monitoring vendors have shipped real-time capabilities by 2026, but the operational maturity to use them effectively is still uneven.

Evidence and examination

AML transaction monitoring is examined more rigorously than almost any other compliance area. Examiners specifically test:

  • Rule rationale. Each rule needs documented design rationale, the specific risk it addresses, and a tuning history showing how thresholds were calibrated. "We use vendor defaults" is no longer accepted.
  • Alert dispositions. Every alert dismissed needs a written rationale that an examiner can review. Sample testing of dismissed alerts is standard during exams.
  • SAR-to-alert ratio. Examiners look at the percentage of alerts that escalate to SARs. Too low (under 1-2%) suggests over-alerting from poor rule tuning. Too high (over 15-20%) suggests under-alerting. The acceptable range is risk-profile dependent.
  • SAR narrative quality. Filed SARs are reviewed for narrative completeness, accuracy of structured fields, and timeliness against the 30-day clock.
  • Tuning records. Documented periodic review of rules and thresholds, with evidence of tuning decisions and their effect on alert quality.
  • Independent testing. Annual independent testing of the AML program, with documented findings and remediation evidence.

The evidence infrastructure to satisfy these expectations needs four properties: completeness (every alert, disposition, SAR filing, tuning decision is recorded), tamper-evidence (records are append-only and ideally hash-chained), framework-tagging (records reference the BSA/AML control they satisfy), and exportability (a customer-level or time-range export completes in minutes, not days). These are the same four properties that drive sponsor-bank continuous monitoring — AML is the single most important domain inside that broader infrastructure.

Frequently asked questions

Stop building your orchestration layer. Start running on it.

Let's talk about what FinQub looks like for your stack — which tools you're running, where the pain is, and how quickly you can eliminate it.

Not ready to book a call? Apply for the Partner Program →