How to Build an AML and Transaction Monitoring System 2026

Every financial institution, fintech startup, and money services business operating in the US, EU, or UK is legally required to monitor transactions for money laundering, terrorist financing, and sanctions violations. This is not optional. The Bank Secrecy Act (BSA), FinCEN regulations, and the EU's 6th Anti-Money Laundering Directive (6AMLD) all mandate it. Violations carry fines that routinely exceed $100M, and individuals can face criminal prosecution.

Yet most compliance teams still rely on legacy platforms built in the early 2000s. These systems generate absurd false positive rates (often 95% or higher), require months of vendor onboarding, and charge six-figure annual license fees. For growing fintechs, this is a problem. You cannot afford a $300K annual platform when you are processing your first million transactions, but you also cannot skip AML monitoring and hope nobody notices.

That is where building a custom AML transaction monitoring system becomes a genuine strategic option. Not for every company. If you are a small neobank processing under 10,000 transactions per month, a managed solution like Unit21 or Alloy is probably the right call. But if you are a payment processor, a crypto exchange, a marketplace handling significant transaction volume, or an institution with complex compliance requirements that off-the-shelf tools cannot handle, building your own system gives you control over detection logic, false positive rates, and the overall compliance workflow.

This guide walks through exactly what it takes to build a production-grade AML transaction monitoring system. We will cover the core components, the machine learning models, the regulatory requirements, and the real costs involved. No hand-waving, no vendor marketing. Just the architecture and decisions you need to get right.

The backbone of any AML system is real-time transaction screening. Every payment, transfer, or withdrawal needs to be evaluated against a set of rules, watchlists, and behavioral models before it clears. The architecture has to be fast (sub-200ms latency for most checks), reliable (zero dropped transactions), and auditable (every decision logged with a clear reason).

The Transaction Ingestion Pipeline

Start with a streaming architecture. Apache Kafka or AWS Kinesis serves as your event backbone. Every transaction event (initiated, pending, completed, reversed) flows through the stream. Downstream consumers pick up events and run them through screening layers. This decouples your core payment processing from your compliance logic, which is critical. You never want a compliance engine bug to block legitimate payments, and you never want payment processing latency to delay compliance checks.

A typical pipeline looks like this:

• Ingestion layer: Kafka topics partitioned by account ID for ordering guarantees
• Enrichment service: Attaches customer profile data, historical transaction patterns, and geographic metadata to each event
• Rules engine: Evaluates the enriched transaction against deterministic rules (velocity checks, amount thresholds, geographic restrictions)
• ML scoring service: Assigns a risk score based on behavioral models
• Sanctions screening: Checks counterparties against OFAC, EU, and UN watchlists
• Decision engine: Combines all signals into a pass/flag/block decision
• Case creation: Flagged transactions generate investigation cases for the compliance team

Latency and Throughput Requirements

For real-time payments (card transactions, instant transfers), your screening pipeline needs to return a decision within 100 to 200 milliseconds. For batch payments (ACH, wire transfers with settlement delays), you have more room, but sub-5-second processing is still the standard. Plan your infrastructure for 10x your current peak volume. AML systems cannot afford to drop transactions during traffic spikes.

Tech Stack for the Pipeline

We recommend Kafka (or AWS MSK for a managed option) for event streaming, Go or Rust for the low-latency screening services, PostgreSQL for transactional data and case management, and Redis for caching customer profiles and rule configurations. Python handles the ML model serving layer, typically behind a FastAPI or gRPC interface. For infrastructure, Kubernetes on AWS or GCP provides the reliability and scalability you need, with Terraform managing the entire deployment.

Sanctions screening is the most legally urgent component of your AML system. If your platform processes a payment involving a sanctioned individual, entity, or country, you are potentially liable for criminal penalties. OFAC (the Office of Foreign Assets Control under the US Treasury) does not care whether you missed the match accidentally. Strict liability applies.

Which Lists You Need to Screen Against

At minimum, your system must integrate the following watchlists:

• OFAC SDN List: The Specially Designated Nationals list is the primary US sanctions list. Updated frequently, sometimes multiple times per week.
• OFAC Consolidated Sanctions List: Includes the SDN list plus additional programs like the Sectoral Sanctions Identifications List.
• EU Consolidated Financial Sanctions List: Required for any business operating in or serving EU customers.
• UN Security Council Consolidated List: Covers individuals and entities subject to UN sanctions.
• UK HM Treasury Sanctions List: Required for businesses serving UK customers post-Brexit.
• PEP (Politically Exposed Persons) databases: Not a sanctions list per se, but screening for PEPs is a regulatory expectation in most jurisdictions.

Fuzzy Matching Is the Hard Part

The real engineering challenge is not downloading the lists. It is matching names accurately. Sanctioned individuals use aliases, transliterated names (Arabic, Cyrillic, Chinese characters have multiple valid romanizations), and common names that produce enormous numbers of false positives. A naive string match on "Mohammed Ali" will flag thousands of legitimate customers.

You need a multi-layered matching approach:

• Exact matching: Direct string comparison after normalization (lowercasing, removing diacritics, standardizing name order)
• Phonetic matching: Algorithms like Double Metaphone or NYSIIS that match names that sound similar but are spelled differently
• Edit distance: Jaro-Winkler or Levenshtein distance to catch typos and minor variations
• Token-based matching: Breaking names into tokens and comparing token overlap, which handles name reordering

Set your match threshold carefully. Too low and you drown your compliance team in false positives. Too high and you miss real matches, which is a regulatory violation. Most production systems use a tiered approach: exact matches trigger an immediate block, high-confidence fuzzy matches create cases for review, and low-confidence matches are logged but not flagged. Plan to spend significant time tuning these thresholds with your compliance officer.

Keeping Lists Current

OFAC updates its lists without a predictable schedule. Sometimes multiple updates happen in a single day. Your system needs an automated ingestion pipeline that polls for updates at least every 4 hours, parses the XML/CSV feeds, diffs against the previous version, and re-screens your existing customer base against new entries. This retroactive screening is a regulatory requirement. When a new name hits the SDN list, you must check whether any of your current customers or recent counterparties match.

Rules-based detection catches the obvious cases: transactions over $10,000 (the BSA reporting threshold), rapid-fire small transactions just below the threshold (structuring), and transactions to high-risk jurisdictions. But sophisticated money laundering does not look obvious. That is where machine learning comes in.

Start with Rules, Then Layer in ML

Do not skip the rules engine. Regulators expect to see deterministic rules for known patterns. These are your table stakes:

• Single transaction amount thresholds (CTR filing at $10,000 for US institutions)
• Structuring detection: multiple transactions within a time window that individually fall below reporting thresholds but collectively exceed them
• Velocity checks: unusually high transaction frequency for a given account
• Geographic risk: transactions involving FATF-listed high-risk jurisdictions
• Counterparty risk: transactions with entities flagged in previous investigations
• Dormant account reactivation: sudden activity on accounts that have been inactive for months

Once your rules engine is operational, you have a labeled dataset (flagged vs. cleared transactions) that you can use to train ML models. This is the right order of operations. Do not try to build an ML-first system without historical labeled data.

Model Architectures That Work

For transaction-level risk scoring, gradient-boosted trees (XGBoost or LightGBM) are the standard starting point. They handle tabular data well, train quickly, and produce interpretable feature importances, which matters because regulators will ask you to explain why a transaction was flagged.

For detecting network-level patterns (layering through multiple accounts, circular transactions), graph neural networks (GNNs) are increasingly effective. Tools like PyTorch Geometric and DGL let you model transaction networks where accounts are nodes and transactions are edges. The model learns to identify suspicious subgraph structures that rules-based systems miss entirely.

For sequence-based patterns (unusual changes in a customer's transaction behavior over time), LSTMs or Transformer-based models trained on transaction sequences can detect behavioral anomalies. These models learn what "normal" looks like for each customer segment and flag deviations.

Feature Engineering

Your model is only as good as its features. High-signal features for AML detection include:

• Transaction amount relative to the customer's historical average
• Time since last transaction
• Number of unique counterparties in the last 7, 30, and 90 days
• Ratio of inbound to outbound transaction value
• Geographic diversity of counterparties
• Round-number transaction frequency (money launderers tend to use round numbers more than legitimate users)
• Account age relative to transaction volume

Handling Class Imbalance

Genuine suspicious activity accounts for less than 0.1% of all transactions. This extreme class imbalance means standard classification metrics are misleading. A model that flags nothing achieves 99.9% accuracy. Focus on precision at high recall thresholds, and use techniques like SMOTE oversampling, cost-sensitive learning, or anomaly detection approaches (Isolation Forest, autoencoders) that do not require balanced classes. The goal is reducing false positives while maintaining the detection rate your compliance team and regulators expect.

Detection is only half the system. When a transaction is flagged, it enters a case management workflow where compliance analysts investigate, document their findings, and decide whether to file a Suspicious Activity Report (SAR) or its equivalent. This workflow is where most legacy systems fall apart, and where a well-designed custom system creates the most value.

Case Management Core Features

Your case management module needs to support the full investigation lifecycle:

• Case creation: Automatically generated from flagged transactions, with all relevant context (customer profile, transaction details, risk scores, matching rules) pre-populated
• Case assignment: Route cases to analysts based on workload, expertise, and case complexity. Senior analysts handle high-risk cases, junior analysts handle routine alerts.
• Investigation workspace: A unified view showing the customer's full transaction history, related entities, previous cases, KYC documents, and a timeline of all account activity. Analysts should not have to switch between five different screens to understand a case.
• Collaboration: Analysts need to add notes, tag colleagues, escalate cases to senior reviewers, and request additional information from the customer
• Decision and documentation: Every case closes with a documented decision (no action, enhanced monitoring, SAR filing, account closure) and a narrative explaining the reasoning
• Audit trail: Every action on a case is logged with timestamps and user attribution. Regulators will review these trails during examinations.

SAR/STR Filing Automation

When an investigation concludes that suspicious activity occurred, US institutions must file a SAR with FinCEN within 30 days of detection. In the EU, equivalent Suspicious Transaction Reports (STRs) go to the relevant Financial Intelligence Unit (FIU). UK firms file SARs with the National Crime Agency.

Filing is tedious. A single SAR requires completing a detailed form (FinCEN Form 111) with structured data about the subject, the financial institution, the suspicious activity, and a narrative summary. Automating as much of this process as possible saves enormous analyst time:

• Pre-populate SAR fields from case data (subject information, account details, transaction amounts and dates)
• Generate draft narrative summaries from investigation notes using template logic or, increasingly, LLM-assisted drafting (with mandatory human review)
• Validate the filing against FinCEN's XML schema before submission to catch formatting errors
• Submit electronically via FinCEN's BSA E-Filing system API
• Track filing status and maintain records for the required 5-year retention period

A good case management system reduces the average SAR filing time from 2 to 3 hours to under 30 minutes. Across hundreds of filings per year, that is a massive productivity gain for your compliance team. If you are building a fintech app that processes significant volume, this workflow automation is not a nice-to-have. It is essential for keeping your compliance team's workload manageable.

Regulators do not just want you to monitor transactions. They want proof that your monitoring program is effective. That means dashboards, reports, and metrics that demonstrate your system is working as designed. When a FinCEN examiner or an EU supervisory authority shows up for an audit, you need to produce this data on demand.

Key Metrics Your Dashboard Must Track

• Alert volume: Total alerts generated per day, week, and month, broken down by rule or model
• False positive rate: Percentage of alerts closed as non-suspicious. If this exceeds 90%, your detection logic needs tuning.
• SAR filing rate: Number of SARs filed as a percentage of total alerts investigated. Regulators compare this against industry benchmarks.
• Average investigation time: Time from alert generation to case closure. Increasing trends indicate staffing or tooling problems.
• Aging cases: Cases open beyond SLA thresholds. FinCEN expects SARs to be filed within 30 days of detection.
• Model performance: Precision, recall, and AUC metrics for ML models, tracked over time to detect model drift
• Sanctions screening coverage: Percentage of transactions screened, list update frequency, and retroactive screening completion rates

Building the Reporting Layer

For the tech stack, we recommend a dedicated analytics database (PostgreSQL with TimescaleDB extension, or a data warehouse like BigQuery or Snowflake) that receives data from your operational database via CDC (Change Data Capture). Build dashboards in Metabase, Grafana, or a custom React frontend with charting libraries like Recharts or Nivo. The key is making these dashboards accessible to compliance officers without requiring engineering support to generate reports.

Automated report generation is equally important. Your system should produce:

• Monthly compliance reports summarizing alert volumes, investigation outcomes, and filing statistics
• Quarterly model performance reports with backtesting results
• Annual BSA/AML risk assessments that feed into your institution's overall compliance program
• Ad-hoc reports for regulatory examinations, exportable to PDF and CSV

Every report should be reproducible. If a regulator asks you to regenerate last quarter's metrics, the numbers must match exactly. This means your reporting pipeline needs to use snapshot data, not live queries that might return different results as data changes. For a deeper look at the costs and complexity of compliance systems like KYC, we have a separate guide that covers the identity verification side of the equation.

Let us get specific about what it actually costs to build this system and how long it takes. These numbers come from our experience building compliance and financial infrastructure for production applications.

Recommended Tech Stack

• Event streaming: Apache Kafka (self-managed) or AWS MSK (managed). Kafka handles the transaction event pipeline with the throughput and ordering guarantees you need.
• Screening services: Go or Rust for low-latency transaction screening. These languages provide the performance profile required for sub-200ms processing.
• ML model serving: Python with FastAPI or gRPC, running XGBoost/LightGBM models for transaction scoring. PyTorch for graph-based and sequence-based models.
• Application backend: Node.js with TypeScript for the case management API and dashboard backend. Strong typing prevents the kind of bugs that are unacceptable in compliance software.
• Database: PostgreSQL for transactional data and case management. Redis for caching customer profiles and rule configurations. TimescaleDB or BigQuery for analytics.
• Frontend: React with TypeScript for the analyst dashboard and reporting interface. Recharts or Nivo for data visualization.
• Infrastructure: Kubernetes on AWS (EKS) or GCP (GKE). Terraform for infrastructure-as-code. Datadog or Grafana for monitoring and alerting.
• Sanctions data: Direct integration with OFAC, EU, and UN feeds, or a commercial provider like Dow Jones Risk & Compliance, Refinitiv World-Check, or ComplyAdvantage for consolidated and enriched data.

Timeline Estimates

Phase 1, Core Screening Engine (8 to 12 weeks): Transaction ingestion pipeline, rules engine, sanctions list integration with fuzzy matching, and basic alerting. This gets you a functional screening system.

Phase 2, ML Models and Case Management (10 to 14 weeks): ML risk scoring models trained on your transaction data, full case management workflow, analyst dashboard, and investigation tools.

Phase 3, SAR Automation and Reporting (6 to 8 weeks): SAR/STR filing automation, regulatory reporting dashboards, model monitoring, and audit trail exports.

Total timeline: 24 to 34 weeks for a production-ready system. This assumes a team of 3 to 5 engineers plus a compliance subject matter expert who defines rules and validates detection logic.

Cost Breakdown

• Development (full build): $250K to $450K depending on team size, complexity, and whether you use commercial sanctions data feeds or build direct integrations
• Commercial sanctions data feeds: $20K to $80K per year for providers like Dow Jones or Refinitiv. Direct OFAC/EU feeds are free but require more engineering to parse and maintain.
• Infrastructure (monthly): $3K to $10K for Kafka clusters, Kubernetes, databases, and ML inference infrastructure
• Ongoing ML model maintenance: Budget 15 to 20% of initial development cost annually for model retraining, rule tuning, and feature updates
• Compliance staffing: $80K to $150K per analyst annually. A small fintech typically needs 2 to 5 analysts depending on transaction volume and alert rates.

Compare this to enterprise vendor solutions like NICE Actimize, Oracle Financial Crime, or SAS AML, which charge $200K to $1M+ annually in licensing fees alone, plus implementation costs that often exceed the license fee. For companies processing high volumes or with complex requirements, a custom build pays for itself within 18 to 24 months. For a broader look at how AI is transforming fintech risk assessment, including credit scoring and underwriting, check out our deep dive on the topic.

Not every company should build a custom AML system. Here is how to decide.

Buy (use a managed platform) if:

• You process fewer than 50,000 transactions per month
• Your compliance requirements are standard and well-served by off-the-shelf tools
• You do not have in-house ML engineering capacity
• You need to be operational within 4 to 6 weeks, not 6 to 9 months

Good managed options include Unit21 (modern UI, flexible rules), Alloy (strong identity and compliance orchestration), ComplyAdvantage (excellent sanctions and PEP data), and Sardine (focused on fraud and AML for fintechs).

Build if:

• You process high transaction volumes where per-transaction vendor pricing becomes prohibitive
• Your business model has unique risk patterns that generic rules cannot capture
• You need full control over detection logic, model tuning, and false positive rates
• Compliance is a core differentiator for your product (e.g., you are a compliance-as-a-service provider)
• You operate across multiple jurisdictions with conflicting regulatory requirements

The Hybrid Approach

Many companies start with a managed platform and gradually replace components with custom-built alternatives as they scale. This is often the smartest path. Use a vendor for sanctions screening and case management in year one, then build custom ML models once you have enough transaction data to train on. Replace the vendor's rules engine with your own when their false positive rates become unacceptable. This reduces upfront risk while preserving the option to own your stack long-term.

What to do right now:

• Audit your current AML program. Identify the biggest pain points: false positive volume, investigation time, filing delays, or missing coverage.
• Talk to your compliance officer about which detection gaps keep them up at night. Their input drives your requirements.
• Map your regulatory obligations across every jurisdiction you operate in. The requirements differ between FinCEN, the EU FIUs, and the UK NCA.
• Evaluate whether your transaction volume and complexity justify a custom build, or whether a managed platform solves the problem at lower risk.

At Kanopy, we build compliance and financial infrastructure for companies that take these problems seriously. Whether you need a full custom AML system, an ML-powered detection layer on top of your existing tools, or help migrating off a legacy vendor platform, we can help you scope it and build it right. Book a free strategy call and let us figure out the right approach for your compliance requirements.