> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wayak.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Transaction anomaly detection
> Identify statistically unusual transactions in real time and route flagged items for immediate review
Fraud, operational errors, and money laundering all leave traces in transaction data — but those traces are easy to miss among millions of daily transactions. Rule-based systems catch known patterns, but novel anomalies slip through. Analysts reviewing alerts manually face high false-positive rates and fatigue, which means genuine threats get buried in the noise.
Wayak takes a data-driven approach to anomaly detection. A playbook runs Python-based statistical analysis on your transaction stream to identify outliers by amount, frequency, counterparty behavior, and timing patterns. Flagged transactions are routed to an agent that provides context — pulling account history, counterparty information, and similar past cases — so your investigations team can act quickly and decisively.
***
## What you need
* **Transaction database** — real-time or near-real-time transaction records including amounts, timestamps, counterparties, channels, and geolocation
* **Core banking system** — customer profiles, account types, typical transaction patterns, and historical baselines
* **Watchlist database** — sanctioned entities, PEP lists, and internal flagged accounts
* **AML compliance manual** — anti-money laundering rules, suspicious activity indicators, and reporting thresholds
* **Investigation procedures** — internal protocols for alert triage, escalation paths, and case documentation standards
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------------- | ------------------------------------------------------------------------------------------------------------ |
| Object | Transaction | Maps to the `transactions` table. Represents a single financial movement with amount, channel, and timestamp |
| Object | Alert | Maps to `alerts` in the monitoring system. Represents a flagged transaction pending investigation |
| Metric | Anomaly Score | Z-score of the transaction amount relative to the customer's 90-day rolling mean and standard deviation |
| Metric | Alert Conversion Rate | Percentage of alerts that result in a confirmed suspicious activity report (SAR) |
| Dimension | Channel | Categorizes transactions by origination channel (branch, ATM, online, mobile, wire) |
| Dimension | Alert Priority | Classifies alerts as critical, high, medium, or low based on anomaly score thresholds |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Transaction Investigator |
| **Role** | Fraud and Anomaly Analyst |
| **Goal** | Provide context and analysis for flagged transactions, help investigators assess alerts, and surface related patterns across accounts |
> You are a transaction investigation analyst specializing in anomaly detection and fraud analysis. When presented with a flagged transaction, you pull the customer's historical transaction profile, identify what makes the transaction unusual, and check for related activity across linked accounts. You present findings objectively with supporting data, and you flag any matches against watchlists. You never make a final determination — you equip investigators with the evidence they need.
Grant access to:
* Transaction database (all channels and transaction types)
* Core banking system (customer profiles, account history)
* Watchlist database (sanctions, PEP lists)
* AML compliance manual knowledge space
* Investigation procedures knowledge space
* Transaction and Alert objects, Anomaly Score and Alert Conversion Rate metrics
**Trigger:** User asks the agent to investigate a specific flagged transaction or alert.
1. Retrieve the flagged transaction details from the transaction database.
2. Pull the customer's 90-day transaction history and compute baseline statistics (mean amount, frequency, typical channels).
3. Identify why the transaction was flagged — which dimensions (amount, timing, counterparty, channel) deviated from the baseline.
4. Check the counterparty against the watchlist database for sanctions or PEP matches.
5. Search for similar transactions across linked accounts or the same counterparty in the last 30 days.
6. Return a structured investigation report with the transaction details, anomaly explanation, watchlist results, and related activity.
**Trigger:** User asks about transaction patterns for a customer, counterparty, or account group.
1. Query the transaction database for all activity involving the specified entity over the requested time period.
2. Compute descriptive statistics (volume, average amount, channel distribution, time-of-day patterns).
3. Identify structuring indicators (e.g., multiple transactions just below reporting thresholds).
4. Compare the entity's behavior to peer group baselines from the core banking system.
5. Return a behavioral profile with charts-ready data, flagged patterns, and comparison to norms.
**Trigger:** User asks the agent to screen a name, entity, or account against watchlists.
1. Search the watchlist database for exact and fuzzy matches against the provided name or entity.
2. If a match is found, retrieve the full watchlist entry (reason, source list, effective date).
3. Pull any existing alerts or cases linked to the matched entity from the monitoring system.
4. Check the AML compliance manual for the required response protocol for the match type.
5. Return the screening result with match confidence, supporting details, and recommended next steps per policy.
***
## Automation
### Playbook: Real-time anomaly detection scan
Set the trigger to **Schedule — Hourly** to scan the latest batch of transactions. For higher-frequency environments, set it to every 15 minutes.
The workflow applies statistical outlier detection to recent transactions and routes anomalies for investigation:
1. **Query** all transactions posted since the last scan from the transaction database.
2. **Query** the 90-day rolling baseline statistics (mean, standard deviation, typical channels) for each transacting customer from the core banking system.
3. **Python code block** — compute the anomaly score for each transaction. The code calculates a Z-score based on the customer's historical mean and standard deviation, then applies additional flags for unusual channel usage, atypical counterparties, and timing anomalies (e.g., transactions outside normal business hours). Transactions exceeding a configurable Z-score threshold are flagged.
The **anomaly scoring** step uses a Python code block to compute Z-scores and apply multi-dimensional outlier detection. You can customize the Z-score threshold (default: 3.0), the lookback window for baselines, and the weighting of each anomaly dimension.
4. **Condition** — check each flagged transaction against the watchlist database. If there is a match, escalate priority to critical.
5. **Loop** — for each flagged transaction, create an alert record in the monitoring system with the anomaly score, contributing factors, and priority level.
6. **Delivery** — notify the investigations team of new alerts.
* **Slack** — post critical and high-priority alerts to `#fraud-alerts` immediately
* **Email** — send a digest of all new alerts to the fraud investigations team lead
* **Webhook** — push alert data to your case management system for automatic case creation
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Monitor portfolio-level risk metrics daily and catch limit breaches before they escalate.
See the full list.