Ask any MLRO at a UK payment processor what occupies most of their compliance team's working day, and the answer is almost always the same: reviewing alerts that should never have been raised in the first place. Industry data from ACAMS and KPMG consistently places the false positive rate at payment firms between 90% and 96% of total alert volume. At an institution processing 500,000 transactions daily, that translates to thousands of alerts generated, worked, and closed every day without a single SAR ever being filed.
The cost is not just operational. It is regulatory. When compliance analysts spend the majority of their time clearing noise, genuine financial crime signals — the ones that should prompt timely SAR filing to the NCA — receive less investigative attention and are more likely to be filed late or not at all. The FCA has cited inadequate investigation quality as a finding in enforcement actions against payment firms precisely because alert volume has outstripped analyst capacity.
Reducing false positives is therefore not a cost-cutting exercise. It is a compliance quality exercise. Here are five strategies that compliance teams are actually implementing to bring alert-to-analyst ratios into a range where quality investigation is possible.
Strategy 1: Peer Group Segmentation
The most common source of false positives in payment firm transaction monitoring is applying a single rule threshold across customer populations with materially different transaction behaviours. A rule that flags transactions above £5,000 as unusual will generate near-constant alerts for a payroll processing client whose average transaction is £4,200 — and will barely register for a low-value consumer remittance customer where the same threshold is genuinely high-risk.
Peer group segmentation addresses this by dividing your customer base into groups with similar transaction patterns and applying distinct rule parameters to each group. Typical segmentation dimensions include: customer type (consumer / small business / corporate), payment corridor (domestic / cross-border / high-risk jurisdiction), average transaction value band, and onboarding channel (direct / agency / third-party introducer).
The JMLSG Guidance (Part I, para 6.3) explicitly supports a risk-based approach to monitoring in which rule parameters reflect the specific risk profile of each customer category. Peer group logic is the operational implementation of that principle. The documentation requirement is that each peer group's parameters must be reviewed and re-justified periodically — typically at least quarterly — and whenever the composition of the peer group changes materially.
Strategy 2: Transaction Profile Baselines
Where peer group segmentation uses category-level parameters, individual customer baseline profiling applies customer-specific expected behaviour to generate alerts only when transactions deviate materially from that customer's own pattern. This is sometimes called behavioural profiling or velocity profiling in transaction monitoring literature.
The approach requires a sufficient history of clean transactions to establish a reliable baseline — typically 60 to 90 days of activity before the baseline is considered stable. During the establishment period, monitoring continues against peer group parameters. Once a baseline is established, the monitoring rule triggers on deviation from the customer's own profile rather than against a peer group average.
Baseline profiling is particularly effective for business customers with predictable transaction patterns — payroll processors, insurance premium collectors, subscription billing platforms — where the transaction signature is regular and high-volume but the per-transaction values and counterparty patterns are stable. The alert generated when a business customer sends a transaction to an entirely new beneficiary geography, or at a time inconsistent with their established operating pattern, is far more likely to be genuinely suspicious than an alert generated purely on value.
Strategy 3: Look-Back Period Calibration
Transaction monitoring rules that aggregate activity over a rolling period — for example, "flag if cumulative transfers to high-risk jurisdictions exceed £10,000 in 30 days" — are sensitive to both the threshold value and the look-back window. Many firms deploy these rules with a generic look-back window that is not calibrated to the actual velocity of transactions in their customer base.
A 30-day window for a firm whose customers transact multiple times daily may aggregate activity that is individually unremarkable but appears suspicious in aggregate. Conversely, a 30-day window for a firm with predominantly weekly transaction patterns may miss genuinely unusual acceleration within a single week.
Look-back calibration involves analysing your actual transaction velocity distribution by customer segment and adjusting the aggregation window to a period that is meaningful for your firm's specific transaction rhythm. This is a technical tuning exercise that requires access to historical transaction data, but the impact on alert volumes — and on the proportion of alerts that represent genuinely novel behaviour — is significant.
Strategy 4: Exclusion List Management
Not all transaction monitoring alerts require the same investigative approach. Payment firms commonly identify categories of transactions that repeatedly generate alerts but are consistently cleared without SAR concern: salary payments to employees, rent payments to commercial landlords, tax payments to HMRC, and similar recurring obligations that have been investigated and assessed as low-risk.
Exclusion lists — or "whitelists" in some system configurations — allow these known-clean counterparty relationships to be excluded from certain rule triggers, eliminating the recurring alert generation without eliminating monitoring of new counterparties or genuinely unusual activity patterns.
The regulatory requirement is that exclusion decisions are documented and approved by the MLRO, with a documented rationale for why the counterparty relationship presents low money laundering risk. Exclusion lists must be subject to periodic review — the FCA has noted that stale exclusions created during onboarding and never subsequently reviewed represent a monitoring gap rather than a calibration decision. The review should reassess whether the counterparty relationship has changed, whether the business rationale remains valid, and whether the risk assessment remains current.
Strategy 5: Tuning Cycle Documentation
The four strategies above are technical and operational. The fifth is procedural, and it may be the most important from an FCA perspective: documenting every tuning decision, its rationale, and its measured effect on alert volumes.
The FCA's review of transaction monitoring systems in enforcement investigations consistently focuses on whether the firm can demonstrate that its monitoring configuration is the product of deliberate, risk-justified decisions rather than default vendor settings. A calibration decision that reduces alert volume by 30% is not inherently concerning to the FCA — a suppression decision is not the same as a failure to monitor. What the FCA requires is evidence that the decision was made by a suitably authorised person, was based on analysis of the firm's actual transaction risk profile, and was documented in a way that supports FCA scrutiny.
Good calibration documentation includes: the rule or parameter being changed, the previous and new values, the analysis that supported the change (including false positive rate data and SAR filing rate data before and after), the date of the decision, the person who approved it, and the scheduled date of the next review of that calibration decision.
The Regulatory Framing
It is worth being explicit about what false positive reduction is not. It is not a strategy to reduce SAR filing. If your overall SAR filing rate decreases as your false positive rate decreases, that should prompt investigation — it may indicate that calibration has gone too far and is now suppressing genuine signals. The objective is to concentrate analyst attention on alerts with genuine investigative value, not to reduce monitoring coverage overall.
The FATF 40 Recommendations (Recommendation 10 on CDD, Recommendation 20 on STR reporting) and the corresponding UK implementation in MLR 2017 are clear that the risk-based approach allows firms to calibrate the intensity of monitoring to the risk level of each customer relationship. Calibration in a low-risk direction must be supported by documented evidence that the risk is genuinely low — not by alert volume management alone.
This article is published for informational purposes. RegSynq Ltd is not authorised or regulated by the Financial Conduct Authority. Nothing in this article constitutes legal advice. Firms should seek independent legal and compliance counsel for guidance specific to their regulatory situation.