AML screening false positives: why they happen and how to reduce them

Four causes account for most of the noise. Homonyms are the largest: common names appear on sanctions and PEP lists just as they do in the general population, so a name-only match can flag hundreds of unrelated people who happen to share a name. Transliteration and spelling variants compound it, because names carried over from non-Latin scripts produce several accepted English spellings of the same listed person, and fuzzy matching tuned to catch all of them catches unrelated names too. Thin identifying data makes both worse: a customer or list record with no date of birth, no address and no secondary identifier forces the engine to match on name alone, the least reliable signal available. Finally, a single static match threshold applied across an entire customer book over-flags low-risk segments while under-scrutinising the ones that genuinely warrant tighter matching.

With traditional name-only screening, the vast majority of alerts turn out to be false positives, meaning most of what a manual review queue processes each day is noise rather than genuine risk. The figure sounds abstract until you trace what it costs. Reviewers facing thousands of low-value alerts develop alert fatigue, and fatigue is exactly what causes a genuine match to be cleared on autopilot alongside the noise around it. It also erodes examiner confidence, because a program that cannot explain why almost all of its alerts were false is harder to defend as risk-based and effective, the standard Bill C-12 now applies to every FINTRAC-regulated program. The rate itself is not the problem to solve; the problem is that clearing it consumes the capacity a team should be spending on the small number of alerts that actually carry real risk and warrant investigation.

No, and the distinction matters. Loosening match thresholds does reduce false positives, but it does so by trading them for missed true matches, which is the opposite of what a compliance program needs. Agentic entity resolution works differently: instead of widening or narrowing a single sensitivity dial, it scores identity coherence across candidate matches, so it can distinguish a genuine but imperfectly spelled match from a coincidental homonym and collapse near-duplicate hits into one scored identity. The reduction comes from precision, not permissiveness. Every hit that survives resolution still carries a plain-language rationale explaining why it was escalated, so clearing noise never comes at the cost of the audit record an examiner expects to see. In practice the controls are not weakened, they are applied more precisely, with the heaviest scrutiny reserved for the matches that actually warrant a reviewer's time.

BriteBase is designed to reduce false positives by up to 80% through agentic entity resolution, without dropping true risk and while keeping a plain-language rationale attached to every hit that survives. The word designed is deliberate: the reduction depends on the data behind the match being rich enough for resolution to work with, so it is framed as what the engine is built to achieve rather than a guaranteed outcome for every book. The mechanism is consolidation rather than suppression. Spelling variants, transliterations and homonyms routinely turn one real party into several separate alerts, and resolution scores those candidates against each other to recognise when they represent the same underlying identity, collapsing them into a single assessment a reviewer can act on once. What reaches the queue after that is far closer to genuine risk than to noise, which is where the reviewer-time saving actually comes from.

Batch re-screening tends to produce a worse false-positive experience, even at the same underlying match rate, because of how the volume arrives. When an entire customer book is matched against updated lists all at once, every list change that touches a common name creates a spike of alerts that floods reviewers on run day and then goes quiet until the next cycle. Continuous monitoring instead applies matching and entity resolution to each relevant change as it happens, so the same volume is spread into a steady, prioritised queue rather than periodic floods. It also closes the exposure window that batch cycles leave open: a customer who becomes a sanctions match the day after a run would otherwise go undetected until the next scheduled cycle, which could be weeks away. Continuous screening surfaces that change close to when it occurs, which is when it is most actionable.