Transaction Monitoring

Transaction monitoring is the automated surveillance of customer activity after onboarding, looking for behaviour that does not fit the customer's profile or that matches known laundering patterns. The monitoring system runs rules and models over transactions, often daily or in near real time, and generates alerts when something stands out. Typical rules include large cash deposits just below a reporting threshold, rapid movement of funds in and out of an account, transactions with high risk countries, round sum transfers, and activity that is inconsistent with the customer's stated business. Each rule has a threshold, and the threshold is a risk decision. Set it too low and the team drowns in alerts, set it too high and real laundering passes unnoticed. Monitoring has to be tuned to the customer, not just to the transaction. A rule that flags a ten thousand dollar transfer might be right for a retail customer but meaningless for a multinational company that moves millions every day. Modern systems therefore use customer segmentation and peer grouping, comparing a customer's behaviour against similar customers and against their own history. A sudden change, such as a dormant account becoming active, or a customer whose usual pattern is domestic payments suddenly sending money to three new countries, is more suspicious than the absolute value alone. This is where the BA's understanding of customer segments and product behaviour becomes valuable, because monitoring rules that ignore the business context generate noise. When an alert is generated, an analyst investigates it in a case management system. They look at the transaction history, the customer's profile, the counterparties, and any related alerts, and they decide whether the activity has a plausible explanation. Many alerts are cleared with a documented reason, for example a property purchase that explains a large transfer. Others are escalated for deeper investigation, and the most serious become suspicious activity reports. The whole process must be completed within defined timeframes, because regulators expect alerts to be worked promptly, not left in a queue for months. System requirements therefore cover alert prioritisation, workload management, documentation standards, and quality assurance checks on closed alerts. Transaction monitoring scenarios are the rules that generate alerts, and each scenario must be designed, tested, and tuned. A scenario might be: a customer sends more than 10,000 euros in a day to a high-risk country. Another might be: a customer who normally sends 500 euros a month suddenly sends 50,000 euros. Another might be: a customer receives funds from five different countries and sends them on to a single beneficiary within 24 hours. Each scenario has a threshold, a time window, and a risk score, and each one must be tested against historical data to measure how many alerts it generates and how many of those alerts are true positives. Threshold tuning is the calibration of the scenarios. A threshold that is too low generates thousands of alerts, most of them false positives, and the operations team cannot triage them all. A threshold that is too high generates few alerts, but misses the true positives. The tuning process runs the scenario against a year of historical transactions, measures the alert volume and the true positive rate at different thresholds, and chooses the threshold that gives the best balance. The tuning must be documented, and must be repeated when the transaction volumes change, when a new scenario is added, or when the false positive rate rises. The alert generation process must be reliable, because a missed alert is a missed suspicious transaction. The monitoring system runs on a schedule, usually daily, and generates alerts for the previous day's transactions. The alerts must be assigned to analysts, must be prioritised by risk score, and must be tracked to closure. An alert that is generated but never assigned is a failure, and an alert that is assigned but never closed is a failure. The requirements must state the schedule, the assignment logic, the prioritisation, and the tracking, and the system must be able to prove that every alert was handled.