AML transaction monitoring

    AML transaction monitoring for banks, fintechs and CASPs.

    Catch structuring, layering, mule networks and sanctions evasion without drowning analysts in false positives. ComplianceSuite pairs 80+ FATF-typology rules with behavioural models, unifies alerts with sanctions and PEP context, and files SARs to FinCEN, NCA, FIU-NET, MAS STRO and FINTRAC in the format each regulator expects.

    • 80+ FATF-typology rule templates
    • Real-time (<300 ms) + post-transaction
    • 42% average false-positive rate
    • SAR/STR filing to 20+ FIUs

    Definition

    What is AML transaction monitoring?

    AML transaction monitoring is the automated, ongoing review of customer transactions against risk-based rules and behavioural models to detect money laundering, terrorist financing, sanctions evasion and fraud. It is a legal requirement under FATF Recommendation 20, the EU AMLR, the US Bank Secrecy Act, and equivalent regimes in the UK, Singapore, Canada and 90+ other jurisdictions.

    Effective monitoring combines rules (deterministic thresholds and typologies) with models (peer-group anomaly detection and behavioural baselines), enriched by the customer's EDD profile and adverse media. Suspicious activity triggers a Suspicious Activity Report (SAR) or Suspicious Transaction Report (STR) to the national Financial Intelligence Unit — mandatory, protected by safe-harbour, and typically due within 30 days.

    See our guides to AML and the AML glossary.

    Capabilities

    What's included.

    Rules + models in one engine

    80+ FATF-typology rule templates plus supervised anomaly models. Author, backtest and deploy without redeploying code.

    Real-time + post-transaction

    Sub-300 ms inline screening for sanctions and high-risk corridors; rolling-window behavioural detection for structuring and layering.

    Explainable alerts

    Every alert shows the triggered rule, the transaction graph, and the customer context — no black box.

    Unified with screening

    Alerts inherit PEP, sanctions and adverse-media status. No context-switching between systems.

    SAR / STR filing

    Structured filing to FinCEN, NCA, FIU-NET, MAS STRO, FINTRAC and 20+ FIUs with pre-populated narratives.

    Alert-quality tuning

    Analyst dispositions retrain the model weekly; auto-suppress repeat false positives with documented rationale.

    How it works

    Four steps from stream to SAR.

    1. Ingest transactions

    Real-time stream via API/Kafka or batch file. Enriched with customer risk profile, PEP/sanctions status, historical baseline and peer-group segment.

    2. Apply rules & models

    80+ typology rules (structuring, layering, mule) plus behavioural models score every transaction. High-risk-corridor and sanctions checks run inline in real time.

    3. Investigate alerts

    Case opens with transaction graph, customer 360, prior alerts and rule rationale. Analyst dispositions in a structured form; escalations routed to L2 / MLRO.

    4. File SAR / STR

    Pre-populated FIU-specific templates (FinCEN 111, NCA SAR, FIU-NET STR, MAS STRO). Digital signature, submission tracking and audit trail.

    Example alerts

    Three real-world alerts and how they are handled.

    RuleScenarioAction
    Structuring — cash depositsRetail customer makes 9 cash deposits of $9,500 over 12 days across 3 branchesAlert routed to L2. Analyst confirms structuring pattern. SAR filed with FinCEN within 30 days. Customer risk score upgraded to high; EDD refresh triggered.
    High-risk corridor + velocitySME customer sends 14 wires totalling €3.2M to a new counterparty in a FATF grey-listed jurisdiction over 5 daysReal-time hold on wire #15. Case opens with source-of-funds request, sanctions re-screen of counterparty, STR filing to national FIU.
    Peer-group anomalyFreelance-designer customer receives €180K inbound from a shell company — 24× their monthly baselineBehavioural model flags outlier. Analyst reviews; documented rationale required. If cleared → auto-suppress rule for 90 days with review reminder.

    Regulatory coverage

    Monitoring & SAR obligations across major regimes.

    RegimeScopeRequirement
    FATF Recommendation 20Global standardObliged entities must promptly report suspicious transactions to the national FIU. Requires ongoing monitoring capable of detecting complex, unusual and structured patterns.
    EU AMLR (Reg. 2024/1624)EU 27Art. 20–23 require risk-based ongoing monitoring, scrutiny of all complex/unusual transactions, and STR filing to the national FIU without delay.
    US Bank Secrecy Act / FinCENUnited States31 CFR 1020.320 requires SAR filing within 30 days of detection for transactions aggregating ≥$5,000 that are suspicious.
    UK MLR 2017 Reg. 28United KingdomOngoing monitoring of transactions and source of funds. SARs to NCA under POCA 2002 s.330; DAML/DATF requests where required.
    MAS Notice 626 §7SingaporeContinuous monitoring against customer's risk profile; STR to STRO under CDSA within 15 business days.
    FINTRAC (PCMLTFA)CanadaSTRs on reasonable grounds to suspect; LCTRs on all cash transactions ≥CAD 10,000; EFTRs on cross-border transfers ≥CAD 10,000.

    Frequently asked questions.

    What is AML transaction monitoring?

    AML transaction monitoring is the ongoing, automated review of customer transactions against risk-based rules and behavioural models to detect money laundering, terrorist financing, sanctions evasion and fraud. It is a legal requirement under FATF Recommendation 20, EU AMLD/AMLR, US Bank Secrecy Act, UK MLR 2017 and equivalent regimes.

    What are the main types of monitoring rules?

    Threshold rules (single or aggregated transactions above a value), velocity rules (frequency in a rolling window), structuring / smurfing (multiple transactions just below a reporting threshold), high-risk corridors (transactions to/from FATF grey or black-listed jurisdictions), round-tripping, dormant-then-active accounts, and peer-group anomaly detection.

    How is transaction monitoring different from sanctions screening?

    Sanctions screening runs at the payment level against sanctions lists (OFAC, UN, EU, UK) to block or hold payments to designated parties. Transaction monitoring runs across the customer's full behaviour — patterns, frequencies, amounts, counterparties — to identify suspicious activity that may not touch a sanctioned party. Both are legally required, and ComplianceSuite unifies them.

    What is a suspicious activity report (SAR / STR)?

    A Suspicious Activity Report (SAR in the US and UK) or Suspicious Transaction Report (STR in EU / most jurisdictions) is the regulatory filing an obliged entity submits to its FIU (FinCEN, NCA, FIU-NET, MAS STRO, FINTRAC) when a transaction or pattern gives rise to suspicion of ML/TF. Filing is mandatory, protected by safe-harbour, and typically due within 30 days of the analyst decision.

    What is a good false-positive rate for transaction monitoring?

    Legacy rule-based systems commonly produce 90–98% false positives. A well-tuned modern platform combining rules, peer-group segmentation and behavioural models targets under 60% false positives on retail books. ComplianceSuite averages 42% across live tier-1 customers, measured on 1.4M alerts (2025).

    Do you support real-time and post-transaction monitoring?

    Both. Sanctions and high-risk-corridor checks run in real time (<300 ms) inline with the payment. Behavioural monitoring, structuring detection and peer-group anomalies run on rolling windows post-transaction, with same-day alerts.

    Can I bring my own rules?

    Yes. The rules engine ships with 80+ FATF-typology templates (structuring, layering, round-tripping, mule accounts) and lets you author custom rules in a visual editor with backtest-on-historical-data before deployment.

    How does the alert investigation workflow work?

    Every alert opens a case with the full customer profile, PEP/sanctions/adverse-media status, transaction graph, historical alerts and rule rationale. Analyst dispositions (true positive, false positive, escalate, file SAR) feed back into the model to auto-clear repeat false positives.

    Cut your alert volume in half.

    Replay 30 days of your own transaction data through ComplianceSuite. We'll show you the alerts your current system missed — and the false positives it created.