By Stuart Watkins, CEO, Zenoo
Most transaction monitoring programmes are designed to answer one question: is this transaction connected to a sanctioned entity? That is necessary. It is also insufficient. Sanctions screening catches known threats, people and entities that have already been identified and designated. The money launderers who are not yet on any list, the fraud patterns that do not match any predefined rule, the structuring behaviours that stay just below your alert thresholds: these require a different approach.
Behavioural transaction monitoring analyses how customers transact over time and identifies patterns that deviate from expected behaviour. It is the difference between checking a name against a list and understanding whether a customer's financial activity makes sense given who they claim to be.
Why sanctions screening alone is not enough
Sanctions screening is a binary check at a single point in time. Is this name on a list? Yes or no. It is essential for compliance, but it addresses only one dimension of money laundering risk.
Consider a customer who passes all sanctions, PEP, and adverse media screening at onboarding. Their identity is verified. Their risk assessment is completed. They are categorised as standard risk. Six months later, their transaction behaviour changes fundamentally. Transaction volumes double. New counterparties appear in jurisdictions they have never transacted with before. The size distribution of their transactions shifts, clustering just below reporting thresholds. None of this triggers a sanctions alert because no sanctioned entity is involved. But the behaviour pattern is consistent with money laundering typologies that FATF and national FIUs have identified as high-risk.
A sanctions-only monitoring programme misses this entirely. A behavioural monitoring programme catches it.
"We had a customer who passed every screen at onboarding and every annual re-screening for three years. Clean as a whistle. But when we implemented behavioural monitoring, we flagged them within two weeks. Their transaction patterns had shifted six months earlier, and nobody noticed because our monitoring was entirely list-based. The behavioural signals were obvious once we were looking for them."
The building blocks of behavioural monitoring
Effective behavioural transaction monitoring rests on four pillars.
Customer baselines. Before you can identify unusual behaviour, you need to define what usual behaviour looks like. A customer baseline is a profile of expected transaction activity derived from the customer's declared business purpose, risk category, and historical transaction patterns. A freelance consultant who typically receives two or three payments per month from UK clients has a very different baseline from an import/export business transacting daily across multiple jurisdictions.
Building accurate baselines requires sufficient transaction history (typically 3 to 6 months of activity) and categorisation that reflects the customer's genuine business model. Generic baselines (e.g., "all retail customers share the same expected pattern") are too coarse to detect meaningful deviations. The more granular your baselines, the more useful your monitoring.
Deviation detection. Once baselines are established, the monitoring system needs to identify when a customer's behaviour deviates from their baseline. The key metrics include: transaction volume (number and total value), counterparty patterns (new counterparties, jurisdictions, concentration), transaction size distribution (changes in average size, clustering near thresholds), velocity changes (acceleration or deceleration of activity), and channel usage (shifts between payment methods or platforms).
Each deviation is not necessarily suspicious on its own. A customer's transaction volume might increase because their business is growing. The monitoring system needs to assess deviations in context, combining multiple signals to distinguish genuine changes in business activity from patterns that warrant investigation.
Typology matching. FATF, national FIUs, and industry bodies publish money laundering and terrorist financing typologies: documented patterns of behaviour associated with specific types of financial crime. Your monitoring system should be configured to detect these typologies, including structuring (splitting transactions to avoid reporting thresholds), layering (moving money through multiple accounts or entities to obscure its origin), round-tripping (sending money abroad and receiving it back through a different channel), and rapid movement (funds entering and leaving an account within a very short period with no economic rationale).
Network analysis. Individual transaction analysis looks at each customer in isolation. Network analysis looks at connections between customers. If two of your customers are transacting with each other in patterns that suggest a coordinated structure, or if a group of your customers share counterparties in a pattern consistent with a laundering network, individual monitoring will not catch it. Network analysis maps these relationships and identifies suspicious patterns across your customer base.
Calibration: the art and science of thresholds
The biggest operational challenge in behavioural monitoring is calibration. Set your thresholds too tight, and every minor fluctuation generates an alert. Set them too loose, and genuine suspicious behaviour goes undetected. Getting the balance right is an ongoing process, not a one-time configuration.
The calibration methodology should start with typology-based thresholds: configure specific detection rules for known money laundering patterns based on FATF and FIU typologies. These rules should be tight because they target specific, documented risks.
Then add statistical deviation thresholds: flag customers whose behaviour deviates from their baseline by more than a defined number of standard deviations. These thresholds should be looser than typology-based rules because they are catching unknown patterns, and the false positive rate will be higher.
Finally, implement contextual filters that suppress alerts when the deviation has an obvious explanation. If a customer's transaction volume increases at the same time as their industry's seasonal peak, that is probably not suspicious. If it increases at a time when their industry is typically quiet, it might be.
"Our first attempt at behavioural monitoring generated 8,000 alerts in the first month. Our team could handle about 500. So we spent three months calibrating: tightening thresholds on some detection rules, loosening others, adding contextual filters, and improving our baselines. By month four, we were down to 600 alerts per month with a genuine hit rate of about 12%. That was useful. 8,000 alerts was not."
Integrating behavioural signals with risk ratings
Behavioural monitoring should not exist in isolation. The signals it generates should feed into your customer risk assessment framework, influencing risk ratings in real time rather than waiting for the next scheduled review.
When a customer's behaviour triggers a monitoring alert, several things should happen. First, the alert is investigated and dispositioned by an analyst (or an AI agent, for routine cases). Second, if the investigation confirms that the behaviour is genuinely unusual, the customer's risk rating should be recalculated to reflect the new information. Third, if the recalculated risk rating triggers a higher risk tier, the customer should be subject to the enhanced due diligence and monitoring associated with that tier.
This creates a feedback loop: monitoring detects behavioural changes, risk ratings update to reflect those changes, and monitoring intensity adjusts to the new risk level. A customer who starts behaving in ways inconsistent with their profile receives more scrutiny. A customer who has been flagged but subsequently returns to normal patterns can have their monitoring intensity reduced.
Technology requirements
Behavioural transaction monitoring at scale requires specific technology capabilities that many compliance teams lack.
Real-time data processing. Behavioural monitoring requires transaction data to be processed in real time or near real time. Batch processing with overnight runs means you are always monitoring yesterday's behaviour. For time-sensitive typologies (like rapid movement of funds), overnight processing is too slow.
Machine learning capabilities. While rule-based detection catches known typologies, machine learning models can identify patterns that no predefined rule would catch. Unsupervised learning algorithms can detect anomalous behaviour without being told what to look for, making them particularly valuable for emerging or novel laundering techniques.
Scalable storage and compute. Behavioural baselines require storing and analysing months or years of transaction history for every customer. For firms with large customer bases and high transaction volumes, this is a significant data engineering challenge.
Integration with your compliance stack. Monitoring alerts need to flow into your case management system, trigger risk recalculations in your customer risk engine, and feed into your SAR filing workflow. If these systems are disconnected, the operational overhead of managing behavioural monitoring manually will overwhelm any benefit.
Getting started
If your current monitoring programme is primarily sanctions-based and you want to add behavioural capability, here is a practical starting point.
Start with your highest-risk customers. Build behavioural baselines for your high-risk customer segment first. This is where the monitoring will have the greatest impact, and the smaller population makes calibration more manageable.
Focus on three typologies. Do not try to detect everything at once. Pick three money laundering typologies that are most relevant to your business model and configure detection rules for those. Structuring, rapid movement, and counterparty concentration are good starting points for most financial institutions.
Accept a learning period. Your first few months of behavioural monitoring will require intensive calibration. False positive rates will be high initially. Baselines will need refinement. Detection rules will need tuning. This is normal. Budget the analyst time for the calibration period and do not judge the programme's effectiveness until calibration is complete.
