Skip to main content
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

Data sources

  • 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

Knowledge spaces

  • 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.
ComponentNameDefinition
ObjectTransactionMaps to the transactions table. Represents a single financial movement with amount, channel, and timestamp
ObjectAlertMaps to alerts in the monitoring system. Represents a flagged transaction pending investigation
MetricAnomaly ScoreZ-score of the transaction amount relative to the customer’s 90-day rolling mean and standard deviation
MetricAlert Conversion RatePercentage of alerts that result in a confirmed suspicious activity report (SAR)
DimensionChannelCategorizes transactions by origination channel (branch, ATM, online, mobile, wire)
DimensionAlert PriorityClassifies alerts as critical, high, medium, or low based on anomaly score thresholds
See building a semantic layer for a step-by-step guide.

​
Agent setup

1

Create the agent

Go to Agent Space → New agent.
FieldValue
NameTransaction Investigator
RoleFraud and Anomaly Analyst
GoalProvide context and analysis for flagged transactions, help investigators assess alerts, and surface related patterns across accounts
2

Set the description

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.
3

Scope data access

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
4

Add skills

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

1

Set the trigger

Set the trigger to Schedule — Hourly to scan the latest batch of transactions. For higher-frequency environments, set it to every 15 minutes.
2

Build the workflow

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.
  1. Condition — check each flagged transaction against the watchlist database. If there is a match, escalate priority to critical.
  2. Loop — for each flagged transaction, create an alert record in the monitoring system with the anomaly score, contributing factors, and priority level.
  3. Delivery — notify the investigations team of new alerts.
3

Configure delivery

  • 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
4

Test and activate

Click Run now to test with live data, then toggle to Active.

​
What’s next

Portfolio risk monitoring

Monitor portfolio-level risk metrics daily and catch limit breaches before they escalate.

All Finance & Banking use cases

See the full list.