False Positives and Alert Triage

A false positive is an alert where the payment party shares a name with a listed person but is not that person. This is extremely common, because many listed names are common ones, and because companies in different countries can share similar names. In a large bank, false positives make up the overwhelming majority of screening alerts, often more than ninety five percent. Each one still has to be reviewed by a trained analyst, because the bank cannot simply assume that a match is harmless. The analyst checks identifiers, searches internal records, looks at the customer's history and documents the reasoning before clearing the payment. That documentation is the evidence a regulator will ask for later. Alert triage is the process of working through the queue efficiently and safely. Alerts are usually prioritised by risk, so a payment to a high risk country or a large value payment is reviewed first, while low risk domestic alerts wait. Many banks use whitelisting, where a customer who has been cleared many times against the same list entry is marked so that future identical matches are cleared automatically or with a lighter review. Whitelisting must be governed carefully, with expiry dates and periodic revalidation, because a whitelist that never expires can hide a genuine change in risk. Good case management tooling shows the analyst the payment, the list entry, the match score and the customer's history on one screen, so decisions are fast and consistent. From a BA perspective, the alert workflow is where requirements get very concrete. Who can clear an alert, who can escalate it, what evidence must be attached, how long can a payment sit in the queue before the customer must be told, and what happens if the analyst is unsure? Service level agreements matter here, because a payment held for sanctions review can miss a value date and cost the customer money. The system must also handle the case where an alert arrives after the payment has already been released, which requires a recall or a report to the regulator. Designing this workflow well is what separates a screening system that works from one that quietly builds a backlog. Alert triage is a workflow with a strict order. The first step is to prioritise: a high-score match on a high-risk corridor is triaged first, and a low-score match on a domestic payment is triaged last. The second step is to gather evidence: the analyst checks the customer record, the payment history, the list entry, and any previous alerts for the same customer. The third step is to decide: is this a true hit, a false positive, or does it need more information. The fourth step is to record the decision, with the reason, so that the next analyst who sees the same customer does not repeat the work. Each step has a deadline, and the deadlines are measured in hours. The triage service level agreement is the promise to the customer. A typical SLA is that 90 percent of alerts are triaged within 4 hours, and 99 percent within 24 hours. The SLA must be measured, and the measurement must be reported, because an SLA that is not measured is not a promise, it is a hope. When the alert volume rises, the SLA is the first thing to suffer, and the operations manager must be able to show whether the problem is the volume, the staffing, or the threshold. The requirements must state the SLA, the measurement, and the escalation when it is breached. Disposition codes are the vocabulary of triage. Each alert is closed with a code: true hit, false positive, no match, or insufficient information. The codes must be used consistently, because the analytics depend on them. A false positive rate calculated from inconsistent codes is meaningless, and a threshold tuned on meaningless data will be wrong. The disposition must be recorded with the analyst's name, the date, and the reason, and the record must be auditable, because the regulator will ask to see it. The requirements must state the code set, the definition of each code, and the mandatory fields for each disposition.