Anti-Money Laundering (AML)
This document provides a detailed overview of how Fraudio's Anti-Money Laundering (AML) Detection product works. It is intended for technical and risk teams who want to understand the underlying detection logic beyond the API layer.
Fraudio's AML product identifies transactions or sequences of transactions that may be associated with money laundering. It analyses patterns across transactions and entities, and generates alerts with supporting evidence for operational review and, where applicable, regulatory reporting.
Scope & Coverage
Money laundering involves disguising the origins of illegally obtained money by passing it through legitimate financial systems. This typically occurs through a series of transactions designed to obscure the source, ownership, or destination of funds. The pattern categories below are flagged when they are possibly linked with money laundering activities.
| Category | Description | Key Indicators |
|---|---|---|
| Account Changes | Monitors suspicious modifications related to a user's email activity and account information | • Sudden shifts in location by accounts • Accounts using several cards • Unexplained email account usage variations |
| Cash Activity (ATM) | Identifies unusual cash (ATM) transaction patterns that may indicate money laundering | • Large cash deposits or withdrawals • High frequency of ATM transactions • Inconsistencies in cash usage vs profile • Round-number deposits or withdrawals |
| Complex Transactions | Identifies intricate financial arrangements used to obscure the true nature or purpose of transactions | • Multiple incoming and outgoing wallet transfers • Rapid layering across different wallets |
| Country Risk | Monitors transactions linked to high-risk or sanctioned jurisdictions | • High frequency of international transfers • Transactions involving FATF-identified high-risk countries • Geographic patterns inconsistent with customer profile • Sudden shift from domestic to cross-border activity |
| High Risk Industries | Targets transactions involving sectors with elevated AML exposure | • Luxury goods and precious metals • Virtual currency providers and unregulated financial services • Real estate, art, legal, or accounting services • High-risk merchant categories |
| High Transaction Amounts | Detects transactions or aggregates exceeding reporting or internal thresholds | • Single transactions ≥ €10,000 • Aggregated activity above reporting limits • Large amounts disproportionate to expected turnover • Unusual high-value payments without justification |
| Structuring (Smurfing) | Identifies deliberate splitting of transactions to avoid reporting thresholds | • Multiple transactions just below reporting limits • Same sender/beneficiary repeating similar amounts • Structuring across multiple channels or instruments • Frequent use of round-number values |
| Layering | Detects complex or indirect fund movement and use of intermediaries to obscure ownership | • Funds moved through multiple accounts rapidly • Shift in card bin usage |
| Network & Relationship Risk | Uncovers organized laundering networks and shell relationships between entities | • Shared IPs, devices, or payment instruments • Circular transaction patterns • Links to previously flagged accounts • Rapid fund movement between connected entities |
| Prepaid & Stored-Value Products | Monitors prepaid card or wallet activity exceeding thresholds or patterns inconsistent with profile | • Transactions exceeding $3,000 monthly • High prepaid reloads or withdrawals • Unusual usage across multiple cards • Anonymous or third-party use |
| Rapid Movement of Funds | Detects quick inflows and outflows suggesting mule or layering activity | • Immediate transfers after receipt of funds • Rapid circular transfers • Transaction bursts |
| Repetition & Value Patterns | Identifies scripted or automated transaction behaviors | • Repeated transactions with same or similar values • Sequential or round-number amounts • High-frequency transactions at short intervals • Structuring disguised as routine activity |
| Unusual Transactions | Detects activity deviating from the customer’s normal behavior | • Sudden volume or value changes • Transactions disproportionate to historical activity • Unusual counterparties or geographies • Deviations without economic justification |
| Volume & Velocity Shifts | Monitors sharp increases in transaction counts or values suggesting layering or cash-out behavior | • Rapid transaction growth • Spikes in velocity or volume over short periods • Large increase in maximum transaction size • Layering or mule activity indicators |
Limitations
The AML product is not intended to cover:
- AML scenarios outside the documented pattern categories – The AML product only focuses on the behaviors listed in the pattern categories above.
- Patterns that cannot be triggered due to missing or incomplete data – Certain models depend on specific inputs. If these fields are missing or inaccurate, those alerts will not fire.
- Cases where systemic data quality issues redefine "normal" behavior – If the incoming transaction data is heavily delayed, incorrect, or inconsistent, the models will learn and baseline against this distorted data.
If your risk appetite or AML concerns extend beyond the current scope, Fraudio can work with you to evaluate and expand coverage.
Alert Types
Fraudio generates two types of alerts required for AML compliance.
Objective (Mandatory) Alerts
Objective alerts are based on clear-cut thresholds and criteria explicitly defined by regulators. These are binary triggers: when a (sequence of) transaction(s) meets or exceeds the specified threshold, an alert is generated regardless of any other risk factors. The criteria are typically unambiguous (e.g., specific amounts, transaction types, or combinations thereof) and leave little room for interpretation.
Examples of objective alert thresholds (Netherlands):
- Cash exchange transactions ≥ €10,000
- Cash deposits ≥ €10,000 in favour of a card or prepaid instrument
- Use of a card or prepaid instrument in a transaction ≥ €15,000
- Money transfers ≥ €2,000, subject to applicable exemptions
These thresholds are implemented through explicit rules that fire automatically when the criteria are met, ensuring consistent and auditable compliance with regulatory requirements.
Clients are responsible for informing Fraudio of any objective reporting requirements that must be included for AML compliance. Thresholds and criteria vary by jurisdiction and regulator.
Subjective (Risk-based) Alerts
Subjective alerts are risk-based and apply when there is reason to believe activity may involve money laundering or terrorism financing. Unlike objective alerts, which rely on fixed thresholds, subjective alerts use a combination of techniques to identify suspicious activity that may not meet specific regulatory thresholds but exhibits characteristics indicative of money laundering.
The detection approach combines behavioral analysis, statistical outlier detection, and AI-based pattern recognition to evaluate deviations from expected patterns. This may include analysis of historical baselines, peer comparisons, unsupervised learning models, and supervised models trained on known money laundering patterns.
This approach enables detection of more sophisticated schemes that may not trigger objective thresholds but nonetheless warrant investigation and potential alert generation based on the overall risk assessment.
Detection Approach
Fraudio's AML detection leverages the same behavioral analysis and statistical techniques as the Merchant-Initiated Fraud (MIF) product. It is not limited to monitoring merchant activity; it also covers other entities such as customer and transaction levels, user email accounts, IP addresses, and more, identifying suspicious activity by detecting deviations from expected behavior patterns.
Core Detection Principles
The detection framework applies the following principles:
- Behavioral baselines: the system builds behavioral profiles comparing current activity to historical patterns (self-comparison) and peer groups (peer comparison)
- Outlier detection: statistical deviations from expected norms are identified using z-score normalization and dynamically determined thresholds
- Pattern recognition: anomalies are evaluated in context to focus on combinations that historically signal money laundering rather than isolated unusual events
The underlying technical implementation—including data enrichment, feature engineering, historical aggregates, peer group analysis, link analysis, and machine learning approaches—is detailed in the Technical Overview section of the Merchant-Initiated Fraud documentation. The same techniques apply to AML detection but operate on customer and transaction entities rather than merchant intervals.
Machine Learning Approaches
Machine learning approaches are primarily used for subjective (risk-based) alerts, where detection relies on behavioral analysis and pattern recognition, while rules are more suitable for objective (mandatory) alerts that require clear-cut thresholds. Fraudio employs a combination of unsupervised, semi-unsupervised, and supervised learning approaches for AML detection:
Unsupervised learning: Unsupervised learning is particularly valuable for AML because there are few labels available—most transactions are legitimate, and confirmed money laundering cases represent only a small fraction of the total transaction volume. These models operate on unlabeled transaction data to identify anomalous patterns that deviate from expected behavior. For example, outlier detection can flag unusual transactions where a customer who typically makes €50–€200 purchases suddenly initiates a €5,000 transaction to a new counterparty in a high-risk jurisdiction—deviating significantly from their established behavioral baseline. While the input data is unlabeled, the models are trained and configured to focus on patterns specifically associated with money laundering activity. This approach enables detection of suspicious activity without requiring extensive historical labels.
Supervised learning: Supervised models leverage historical labels and case outcomes to recognize known money laundering patterns. These models are trained on confirmed cases where money laundering activity has been verified, enabling them to identify similar patterns in new transactions. Given the sparsity of AML labels, supervised learning is most effective when combined with unsupervised techniques: supervised models can identify patterns similar to known cases, while unsupervised methods handle the vast unlabeled space where new schemes may emerge.
The combination of these approaches provides comprehensive coverage: unsupervised learning detects novel schemes and supervised learning leverages known patterns for high-confidence alerts.
Rules
Rules are primarily used for objective (mandatory) alerts that require clear-cut thresholds and binary triggers based on regulatory requirements. Fraudio offers a wide range of customizable rules that can be tailored for different operational needs. Depending on the type of rule, they can be configured to generate reports in a non-realtime format or set up for real-time transaction monitoring and reporting.
You can use robust industry statistics to pinpoint transaction anomalies. Examples are the average transaction value in the gambling industry, or the standard deviation of amounts in Malta.
For an overview on how to set rules, please visit: Fraudio's Rules User Guide
Scenario Design
The scenario design framework described below serves as a guideline to guide our integration flow. The specific implementation may vary based on client requirements, regulatory environment, and operational constraints.
Designing AML scenarios is a critical process that translates regulatory and risk-based requirements into practical detection mechanisms. Fraudio's AML Framework provides a structured approach to designing, validating, and optimizing scenarios that combine rule logic and AI-driven intelligence.
Integration Overview
AML integration consists of three key phases that guide the overall implementation:
Functional Integration: Working together to understand your regulatory compliance requirements, identify gaps between your needs and Fraudio's offering, and scope the necessary customizations. This includes understanding your licensing jurisdiction, regulatory reporting requirements (SAR/STR formats), and initiating the scenario design process.
Technical Integration: Setting up the data pipeline to send transactions to Fraudio's API endpoints. Technical teams collaborate to ensure transactions are correctly formatted and transmitted, focusing initially on critical and required fields. Detailed technical integration guidance is available in our Technical Integration Guide.
Live Phases: Once the system goes live, the solution evolves through three iterative phases:
- Warm-up: Implementing required rules and patterns, ensuring all relevant transaction fields are transmitted, and enabling initial detection capabilities
- Tuning: Fine-tuning rule thresholds and AI model configurations based on feedback and performance metrics
- Supported ML: Ongoing monitoring, model updates, and continuous improvement as the system adapts to evolving patterns
Upon request, the Fraudio Support team can provide a detailed document covering all the steps described in the integration overview and scenario design process.
The following five steps describe the detailed iterative process that is followed for scenario design:
1. Translating Requirements into Scenarios
Each AML requirement—whether derived from regulation, internal policy, or typology analysis—should be converted into a detection intent.
Fraudio recommends structuring this translation in three layers:
| Layer | Purpose | Example |
|---|---|---|
| Regulatory Objective | Identify the intent behind the rule | Detect structuring (smurfing) activity |
| Analytical Definition | Define measurable behavior | Multiple deposits just below threshold within 24 hours |
| Operational Rule or AI Feature | Implement detection mechanism | SUM(transactions < €10,000 per customer per day) > N |
This hierarchy ensures that every detection rule or AI model traceably supports a compliance requirement.
2. Scenario Construction
Fraudio AML scenarios are composed of modular components that define what to detect, how to evaluate it, and how to interpret outcomes. Each scenario blends domain knowledge, statistical analysis, and contextual intelligence to deliver interpretable, risk-adjusted results.
Fraudio’s AML Framework defines the following core elements:
Trigger Conditions:
The logical and transactional predicates that determine when a scenario should be activated.
Examples include sudden spikes in transaction frequency, abnormal counterpart relationships, or deviations from peer group norms.
Trigger are optimized for low latency to support both real-time and asynchronous evaluations.Parameters:
Parameters define the quantitative and temporal scope of evaluation. These include thresholds (e.g., transaction amount limits), time windows (e.g., daily, weekly, or rolling periods), and aggregation levels (e.g., per customer, merchant, or network node).Risk Factors:
Each scenario incorporates contextual variables that enrich the detection logic.
Risk factors may include jurisdictional risk, customer type, onboarding channel, product category, transaction corridor, and entity network exposure. These factors are weighted to produce a composite risk score that determines the alert’s priority.
- Model Outputs (optional):
AI and machine learning components can augment or even substitute rule-based evaluations.
Model explainability is ensured by exposing contributing features and statistical reasoning to compliance teams, enabling human validation and regulatory audit readiness.
Together, these components allow Fraudio’s AML scenarios to detect both known typologies and emerging behavioral anomalies, offering flexibility to adapt as financial crime patterns evolve.
3. Incorporating AI and Behavioral Intelligence
AI components extend scenario capabilities by detecting subtle or non-linear relationships that traditional rules may overlook.
Fraudio’s AML Framework integrates multiple AI layers that operate alongside deterministic logic to enhance coverage, accuracy, and adaptability.
Examples include:
- Detecting unusual transaction velocity, peer-group deviations, or emerging structuring patterns.
- Analyzing entity networks to uncover indirect relationships between customers, merchants, or counterparties.
- Leveraging embedding models to identify clusters of entities with similar transactional behaviors that deviate from the norm.
- Using anomaly detection models to flag outliers that cannot be explained by known patterns or typologies.
AI outputs are integrated within the rule engine, allowing hybrid evaluation where model scores influence or trigger scenario logic. Each prediction is accompanied by explainability metadata, exposing the key behavioral and contextual features that contributed to the outcome.
Fraudio’s behavioral intelligence system continuously learns from labeled case management feedback, enabling models to adjust to evolving customer profiles and typologies.
Model governance ensures version control, validation tracking, and periodic retraining, maintaining transparency and regulatory readiness.
Together, these AI-driven mechanisms strengthen scenario performance, reduce false positives, and enable proactive detection of complex or previously unseen laundering behaviors.
4. Calibration and Validation
Fraudio’s AML Framework emphasizes continuous scenario optimization through a structured calibration and validation process that balances detection effectiveness, operational efficiency, and regulatory traceability.
Calibration:
Scenario parameters and thresholds are periodically adjusted to maintain the right balance between sensitivity and false positives. Calibration routines consider transaction volume trends, customer segmentation, and historical alert outcomes.Validation:
Each scenario is validated using historical data, known SAR/STR cases, and synthetic benchmarks. Validation ensures that scenarios behave as intended, that risk scores align with business relevance.
Results are version-controlled, and validation reports can be reviewed or exported for audit and regulatory evidence.Drift Monitoring:
Fraudio continuously monitors data distributions, model stability, and alert-to-case conversion ratios to detect when scenario effectiveness begins to degrade. Early drift indicators trigger a recalibration cycle or model retraining to ensure sustained performance over time.
Fraudio’s monitoring dashboards visualize these metrics — including precision, recall, false positive ratio, and case conversion rate — enabling compliance and data science teams to collaborate effectively in improving detection quality.
5. Governance and Documentation
Fraudio’s AML Framework establishes a structured governance lifecycle that spans design, approval, deployment, and ongoing review.
Each scenario must be version-controlled and documented with:
- Business Rationale and Regulatory Mapping: Linking each detection logic or AI model to the corresponding AML requirement, typology, or internal risk policy.
- Technical Implementation and Parameter Set: Recording the rule logic, data dependencies, thresholds, and AI configuration used in production.
- Performance Metrics and Validation Results: Capturing scenario accuracy, precision, recall, false positive ratio, and recent validation outcomes.
- Approval and Review History: Maintaining timestamps and responsible owners for each configuration change, including calibration or model retraining cycles.
Change logs and validation summaries can be exported for regulators or auditors, ensuring that every alerting component — from rule-based logic to AI models — remains explainable, accountable, and aligned with compliance obligations.
Fraudio Alert Report
The response message that Fraudio provides is in Json format. An example response with one alert report:
[
{
"report":
{
"referenceid": "857531",
"alertdate": "2024-02-01T12:00:00Z",
"indicator": "mandatory",
"priority": 1,
"reason": "Transaction exceeds a total amount of 15k.",
"startdate": "2024-01-31T20:45:07Z",
"enddate": "2024-01-31T20:45:07Z",
"totaltransactions": 1,
"totaleuroamount": 24000.00
},
"entities": [
{
"entitytype": "merchant",
"id": "11205264-221h-g0fe-99c8-7089ca397f6e",
"name": "Axe",
"kyclevel": 3
}
],
"transactions": [
{
"transactionid": 1335112,
"amount": 24000.0,
"currency": "EUR",
"timestamp": "2024-01-31T20:45:07Z",
"transactiontype": "auth_capture",
"sender": {
"entitytype": "cardtoken",
"id": "1234",
"name": "Tom K.",
"streetaddress": "Ace 12, Lisbon",
"country": "POR",
},
"receiver": {
"entitytype": "merchant",
"id": "11205264-221h-g0fe-99c8-7089ca397f6e",
"name": "Baker & Sons",
"streetaddress": "16th Street 47 W 13th St, New York",
"country": "USA",
"bankaccountnumber": "RO09PORL8297336485969785",
}
}
]
}
]
The report contains essential and high level information of the alert that is generated:
- Reference ID: A unique identifier for the report, helping in tracking and referencing.
- Alert Date: The date and time, in UTC, when the alert was generated.
- Indicator: Indicates the nature of the report. Accepted types:
mandatory: Mandatory alerts generated due to specific regulatory requirements. Also known as objective reports.risk-based: Alerts generated based on the risk identified for a specific pattern and configuration during the SIRA. Also known as subjective reports.
- Priority: Priority field that helps ordering the alerts in terms of priority. The priority (can be based on total amounts for example) is determined with the client and can be any integer.
- Reason: The reason for the alert.
- Start Date and End Date: Specifies the first and last date, in UTC, of the sequence of transactions that triggered the alert.
- Total Transactions: The total number of transactions in the sequence of transactions that triggered the alert.
- Total Euro Sum: The aggregate amount of the sequence of transactions that triggered the alert, in Euros.
The "entities" section of the JSON output provides detailed information about the parties involved in the transactions that are under scrutiny in the AML report. Each entity is described by a set of attributes that help in identifying and understanding its role in the transactions.
- Entity Type: Specifies the role or nature of the entity in the context of the transactions. The entities can be any entity that is identified within the data. Possible entities:
merchant: The name or identifier of the merchant. This field uniquely identifies the merchant.mid: The MID, or Merchant ID, is a unique identifier assigned to a merchant by their payment processor. It's important to note that the MID does not uniquely identify the merchant, but rather it identifies the merchant's account. This is because a merchant can have multiple MIDs, as they may have separate merchant accounts for different aspects of their business.cardtoken: The card token is the encryption that is used to identify the credit card.cardholder: The name or identifier of the cardholder.
- ID: A unique identifier assigned to the entity.
- Name: The name of the entity.
- KYC Level: Stands for "Know Your Customer" level, which indicates the depth of verification the entity has undergone.
The "transactions" section of the JSON output elaborates on the individual transactions that have been flagged in the AML report. Each transaction is described by a comprehensive set of fields that detail the transaction's characteristics and the parties involved:
- Transaction ID: A unique identifier for the transaction, helping in tracking and referencing.
- Amount: The monetary value of the transaction.
- Currency: The currency in which the transaction amount is denominated.
- Timestamp: The date and time, in UTC, when the transaction occurred.
- Transaction Type: Indicates the nature of the transaction.
- Sender and Receiver: These are the entities that are involved in the transaction. The 'sender' denotes the entity dispatching funds, while the 'receiver' is the beneficiary.
- Entity Type: Describes the sender/receiver's nature in the transaction.
- ID: A unique identifier for the sender/receiver.
- Name: The name of the sender/receiver.
- Street Address: The physical address of the sender/receiver.
- Country: The country where the sender/receiver is located.
- Bank Account Number: The bank account number of the sender/receiver.